|
List Info
Thread: IETF 67 L3VPN notes
|
|
| IETF 67 L3VPN notes |
|
2006-11-07 22:50:32 |
Attached are the notes I promised to make.
--
[Ville Hallivuori][vph iki.fi][http://www.iki.fi/vph/]
[ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F
2B 07 5D]
[ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4
5854 3419]
[ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291
8061 C24E]
Note: these notes are not word for ford -- instead I tried
to write
down somewhat shortened version what was said. Some comments
were
missed.
13:02 Agenda Bashing
Ron: Two presentations and one tutorial about L3VPN
multicast.
13:03-13:07 Working Group Status - R. Bonica, R.Wilder
See slides.
13:07-14:04 Multicast VPN tutorial - Bruce Davie
draft-ietf-l3vpn-2547bis-mcast-03
Bruce:
Motivation: customers with IP multicast traffic would
like to use
VPN services.
Current deployments:
-Based on draft-rosen-vpn-mcast-08.txt
-PE routers do not hold (S, G) state for individual
customers. However there is some per customer
state in P routers.
-PE routers exchange customer routing information
using PIM.
-Maps all (S, G) of any single VPN to single (S, G)
group in
P-network. Uses GRE encapsulation to perform this
mapping.
-All PEs participating same VPN joint to same
Default-MTD.
Additional data-MTDs can be created for high
bandwidth
C-groups.
-Default MTD is also used by for PIM peering
between PEs.
-Shortcomings: at least one multicast P-group per
customer,
multicast packets are not MPLS encapsulated, only
PIM is
supported for building core trees, inter-AS
challenges, use of PIM
between PE-routers.
???1: Is there considerations for using MPLS P2MP trees
in the
draft?
Bruce: New draft contains that option. The presentation
so far
has been about the old draft.
???2: One of the reasons in rosen draft for using regular
multicast was
to support existing networks that already have
non-VPN
multicast capability. This should be kept in mind,
as we can not
require upgrades in all P-routers for MVPN support.
Bruce: (continuing presentation) PMSI: P-Multicast
Service
Interface. Separates tree from service. Groundwork
that
allows use of multiple protocols. Three types
PMSIs:
-MI-PMSI: multi-point all->all.
-UI-PMSI: unidirectional some->all.
-S-PMSI: unidirectional selective some->some.
Types of trees:
-Inclusive: all PEs for given MVPN
-Selective: some PEs for given MVPN
-Aggregate: all/some PEs for multiple MVPNs
PMSI is scoped to single tunnel. PMSI can be
instantiated by
one or more tunnels. Tunnels may be instantiated by
various
protocols
Ron: Question for slow learners: PEs build PIM
adjacencies although
there may be multiple hops between them. To do this
tunnel is
needed. MI-PMSI scales well, other types are more
efficient. Go on now, I get it now ;)
Bruce: You are jumping ahead. This will become clear
when I go on
with the presentation.
Ron: ???
???3: Clarification question: why S-PMSI are only
unidirectional?
Bruce: Don't worry about uni/multi directional trees.
The slides
are simplified.
???4: S-PMSI would typically be uni-directional.
Bi-directional
trees would be possible, however motivation for
this is
be unclear.
???5: ???
Eric ????: Amused about people already pointing missing
options, when
there are so many of them already.
Bruce: Can map multiple PMSIs onto one tunnel and reduce
P-state.
Mapping of old terminology:
-Default MTD is MI-PMSI instantiated by PIM
shared tree or
set of PIM source trees.
-Data MTD is S-PMSI instantiated by PIM source
tree.
Moving to presenting the new draft.
Auto-discovery
-New address-family to discovering PEs
belonging to MVPN
and tunnel information for these PEs.
-Tunnel information is not intended for
negotiation of
tunnel methods -- all PEs must be configured
with
compatible tunneling settings.
Jackop Reichter: Clarification: tunnel attribute
contains also
tunnel ID that PE will use transmitting
traffic.
???6: Does tunnel id identify source or destination?
Bruce: Source.
Ron: Does auto-discovery replace PIM-adjacency for
multicast
membership discovery?
Bruce: No. This is only auto-discovery.
Jackob Reichter: Ingress replication is exception -- for
it auto-discovery
advertisements contain receive
information,
Bruce: (continuing presentation) Aggregation:
-Two conflicting goals: P-state (scalability)
and
optimality.
-Original Rosen draft allowed either, however
no middle
road.
-New draft solves this by allowing lots of
options.
PE-PE routing exchange:
-Per customer PIM peering among PEs over
emulated LAN.
-PIM hellos can be eliminated, bug Join/Prunes
remain.
-In new draft BGP is proposed as PIM
replacement.
-BGP is more in line with regular VPNs. However
information carried by BGP is basically same
that is
transmitted in PIM.
-BGP router reflectors performs join
suppression.
Inter-AS
-Old rosen draft approach: tunnels spans
multiple ASes.
-New draft also allows splicing tunnels from
different ASes.
-Inter-AS overlay tunnels
Other issues:
-RPF establishment
-Duplicate detection
-C-RP engineering. Try to avoid traffic via
SP-network to
RPs. Two solutions described in the new draft.
Conclusions:
-WG draft builds on rosen draft without
obsoleting it
-Rosen draft not yet obsolete -- it describes
what is
currently deployed.
-Separation of service and mechanism.
-Aggregation support.
-More inter-AS options.
-Allow single instance of BGP to carry C-(S,G)
information between PEs instead of multiple
PIM
instances.
Who is less after presentation? A: Quite many.
???7: Question about how much overhead PIM really
causes.
Bruce: After hellos are suppressed, there still remains
periodic
joins prunes.
???7: Applicability of PIM and BGP are implementation
dependent. Which should be used.
???8: Suitable set of mandatory options is missing.
Draft is
currently patchwork and this is concern for
operators.
Jackob Reichter: PIM hellos might be useful -- BGP
session only
indicates that BGP is up, not that BGP is up.
With PIM you follow VR model, so with multiple
operators
there is direct peering and no hierarchy. This
subverts ASBR
control on peering.
???9: All of PIM is transported in BGP. This make it
quite
complex. Upstream targeted messages in BGP are
complex. While lightweight, it makes BGP lot more
complex
and more hard to manage.
???10: Disagrees. People should read draft -- the
mechanism are
actually quite simple.
Jackob Reichter: MLDP is also supported as CE-PE
protocol.
???9: ???
14:04-14:15 Clarification to 4364 regarding BGP RD - Luca
Martini
draft-martini-l3vpn-rd-zero-00
Luca: -RD has 3 types, 2 types use AS numbers. AS value
0 is
reserved, so RD value 0 violates RD type 0.
-Make RD value 0 to illegal to receive (in
non-nexthop).
Jackob Reichter: few questions. Also as 65k is also
reserved. Should it also be outlawed. Should also
RDs
containing invalid IPs be outlawed.
Luca: RFC speaks about RD 0, so it is special case.
Luca: What you propose?
Jackob: Nothing.
Ron: It goes without question that if it can not be
sent, it
should not be accepted.
Jackob: RFC is not clear enough,
???10: Should update in next version of the draft.
Jackob Reichter: file bug report to RFC editor.
???10: RFC editor is quick way to fix it.
???11: There is nothing wrong about creating new RFC for
fixing
this.
???10: Either way is ok.
Bill ?: RFC editor bug fix queue is 2 year long, so
procedure is
broken.
???10: There will be attempt to fix RFC editor process
eventually.
Ron: Errata or new RFC.
Ron: Hard to compare.
Jackob Reichter: must be in mailing list.
Ron: Will be decided in mailing list.
14:15-14:23 Requirements for delivering MPLS Services over
L3VPN - Kenji Kumaki
draft-kumaki-l3vpn-e2e-rsvp-te-reqs-02
Kenji: draft to clarify issues for e2e MPLS TE LSP over
MPLS
VPNs.
-Presented several application scenarios (see
slides)
-PEs choose correct P-TE tunnels based on
local policy
-PEs perform CAC on P-TE tunnels
-Fast protection between CEs.
-Changes from -01: added applications scenarios.
-Remaining issues: more requirements?
-Next actions_ need more comments and feedback
from
WG. Request WG to accept this as WG documents.
Ron: can we discuss it now or in mailing list?
???10: We are in middle of rechartering, so either is
ok.
Ron: show of hands: is this within charter? More yes
than no. No
clear margin so will discuss on mailing list.
Ron: thats all.
|
|
| IETF 67 L3VPN notes |
|
2006-11-09 19:32:24 |
|
Hey Ville,
did you take notes in MPLS too?
any chance I could have a copy if you did?
Giles
On 11/7/06, Ville Hallivuori < vphiki.fi">vphiki.fi>; wrote:
Attached are the notes I promised to make.
--
[Ville Hallivuori][ vphiki.fi">vphiki.fi
][http://www.iki.fi/vph/]
[ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F 2B 07 5D]
[ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4 5854 3419]
[ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291 8061 C24E]
|
| IETF 67 L3VPN notes (updated version) |
|
2006-11-09 22:51:02 |
I have received some corrections and attributions to the
notes. For
sake of completeness I have attached the updated notes in
this message.
On Wed, Nov 08, 2006 at 12:50:32AM +0200, Ville Hallivuori
wrote:
> Attached are the notes I promised to make.
--
[Ville Hallivuori][vphiki.fi][http://www.iki.fi/vph/]
[ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62 5D 87 47 9D 3F
2B 07 5D]
[ID 58543419][FP20=8731 941D 15AB D4A0 88A0 FC8F B55C F4C4
5854 3419]
[ID 8061C24E][FP20=C722 12DA 841E D811 DBFE 2FB3 174C E291
8061 C24E]
Updated version. Attributions and some additions by Thomas
Morin and
Yakov Rekhter.
Note: these notes are not word for ford -- instead I tried
to write
down somewhat shortened version what was said. Some comments
were
missed.
13:02 Agenda Bashing
Ron: Two presentations and one tutorial about L3VPN
multicast.
13:03-13:07 Working Group Status - R. Bonica, R.Wilder
See slides.
13:07-14:04 Multicast VPN tutorial - Bruce Davie
draft-ietf-l3vpn-2547bis-mcast-03
Bruce:
Motivation: customers with IP multicast traffic would
like to use
VPN services.
Current deployments:
-Based on draft-rosen-vpn-mcast-08.txt
-PE routers do not hold (S, G) state for individual
customers. However there is some per customer
state in P routers.
-PE routers exchange customer routing information
using PIM.
-Maps all (S, G) of any single VPN to single (S, G)
group in
P-network. Uses GRE encapsulation to perform this
mapping.
-All PEs participating same VPN joint to same
Default-MTD.
Additional data-MTDs can be created for high
bandwidth
C-groups.
-Default MTD is also used by for PIM peering
between PEs.
-Shortcomings: at least one multicast P-group per
customer,
multicast packets are not MPLS encapsulated, only
PIM is
supported for building core trees, inter-AS
challenges, use of PIM
between PE-routers.
Dimitri Papadimitriou: Is there considerations for using
MPLS P2MP
trees in the draft?
Bruce: New draft contains that option. The presentation
so far
has been about the old draft.
Yiqun Cai: One of the reasons in rosen draft for using
regular
multicast was to support existing networks that
already have non-VPN
multicast capability. This should be kept in mind,
as we can not
require upgrades in all P-routers for MVPN support.
Bruce: (continuing presentation) PMSI: P-Multicast
Service
Interface. Separates tree from service. Groundwork
that
allows use of multiple protocols. Three types
PMSIs:
-MI-PMSI: multi-point all->all.
-UI-PMSI: unidirectional some->all.
-S-PMSI: unidirectional selective some->some.
Types of trees:
-Inclusive: all PEs for given MVPN
-Selective: some PEs for given MVPN
-Aggregate: all/some PEs for multiple MVPNs
PMSI is scoped to single tunnel. PMSI can be
instantiated by
one or more tunnels. Tunnels may be instantiated by
various
protocols
Ron: Question for slow learners: PEs build PIM
adjacencies although
there may be multiple hops between them. To do this
tunnel is
needed. MI-PMSI scales well, other types are more
efficient. Go on now, I get it now ;)
Bruce: You are jumping ahead. This will become clear
when I go on
with the presentation.
Ron: ???
Dimitri Papadimitriou: Clarification question: why
S-PMSI are only
unidirectional?
Bruce: Don't worry about uni/multi directional trees.
The slides
are simplified.
Thomas Morin: S-PMSI would typically be uni-directional.
Bi-directional
trees would be possible, however motivation for
this is
be unclear.
Bruce: "You meant bidir-PMSI not bidir-trees"
Eric Rosen: Amused about people already pointing missing
options, when
there are so many of them already.
Bruce: Can map multiple PMSIs onto one tunnel and reduce
P-state.
Mapping of old terminology:
-Default MTD is MI-PMSI instantiated by PIM
shared tree or
set of PIM source trees.
-Data MTD is S-PMSI instantiated by PIM source
tree.
Moving to presenting the new draft.
Auto-discovery
-New address-family to discovering PEs
belonging to MVPN
and tunnel information for these PEs.
-Tunnel information is not intended for
negotiation of
tunnel methods -- all PEs must be configured
with
compatible tunneling settings.
Yakov Rekhter: Clarification: tunnel attribute contains
also
tunnel ID that PE will use transmitting
traffic.
Dimitri Papadimitriou (?): Does tunnel id identify
source or destination?
Bruce: Source.
Ron: Does auto-discovery replace PIM-adjacency for
multicast
membership discovery?
Bruce: No. This is only auto-discovery.
Yakov Rekhter: Ingress replication is exception -- for
it auto-discovery
advertisements contain receive
information,
Bruce: (continuing presentation) Aggregation:
-Two conflicting goals: P-state (scalability)
and
optimality.
-Original Rosen draft allowed either, however
no middle
road.
-New draft solves this by allowing lots of
options.
PE-PE routing exchange:
-Per customer PIM peering among PEs over
emulated LAN.
-PIM hellos can be eliminated, bug Join/Prunes
remain.
-In new draft BGP is proposed as PIM
replacement.
-BGP is more in line with regular VPNs. However
information carried by BGP is basically same
that is
transmitted in PIM.
-BGP router reflectors performs join
suppression.
Inter-AS
-Old rosen draft approach: tunnels spans
multiple ASes.
-New draft also allows splicing tunnels from
different ASes.
-Inter-AS overlay tunnels
Other issues:
-RPF establishment
-Duplicate detection
-C-RP engineering. Try to avoid traffic via
SP-network to
RPs. Two solutions described in the new draft.
Conclusions:
-WG draft builds on rosen draft without
obsoleting it
-Rosen draft not yet obsolete -- it describes
what is
currently deployed.
-Separation of service and mechanism.
-Aggregation support.
-More inter-AS options.
-Allow single instance of BGP to carry C-(S,G)
information between PEs instead of multiple
PIM
instances.
Who is less after presentation? A: Quite many.
Dimitri Papadimitriou: Question about how much overhead
PIM really causes.
Bruce: After hellos are suppressed, there still remains
periodic
joins prunes.
Dimitri Papadimitriou: Applicability of PIM and BGP are
implementation
dependent. Which should be used.
Thomas Morin: Suitable set of mandatory options is
missing. Draft is
currently patchwork and this is concern for
operators.
Yakov Rekhter: PIM hellos might be useful -- BGP session
only
indicates that BGP is up, not that PIM is up.
With PIM you follow VR model, so with multiple
operators
there is direct peering and no hierarchy. This
subverts ASBR
control on peering.
Venu Hemige: All of PIM is transported in BGP. This make
it quite
complex. Upstream targeted messages in BGP are
complex. While lightweight, it makes BGP lot more
complex
and more hard to manage.
Thomas Morin: Disagrees. People should read draft -- the
mechanism are
actually quite simple.
Yakov Rekhter: MLDP is also supported as CE-PE protocol.
Thomas Morin: "applicable to not only carrier's
carrier but
enterprise MPLS"
14:04-14:15 Clarification to 4364 regarding BGP RD - Luca
Martini
draft-martini-l3vpn-rd-zero-00
Luca: -RD has 3 types, 2 types use AS numbers. AS value
0 is
reserved, so RD value 0 violates RD type 0.
-Make RD value 0 to illegal to receive (in
non-nexthop).
Yakov Rekhter: few questions. Also as 65k is also
reserved. Should it also be outlawed. Should also
RDs
containing invalid IPs be outlawed.
Luca: RFC speaks about RD 0, so it is special case.
Luca: What you propose?
Yakov Rekhter: Nothing.
Ron: It goes without question that if it can not be
sent, it
should not be accepted.
Yakov Rekhter: RFC is not clear enough,
???10: Should update in next version of the draft.
Yakov Rekhter: file bug report to RFC editor.
???10: RFC editor is quick way to fix it.
???11: There is nothing wrong about creating new RFC for
fixing
this.
???10: Either way is ok.
Bill ?: RFC editor bug fix queue is 2 year long, so
procedure is
broken.
???10: There will be attempt to fix RFC editor process
eventually.
Ron: Errata or new RFC.
Ron: Hard to compare.
Yakov Rekhter: must be in mailing list.
Ron: Will be decided in mailing list.
14:15-14:23 Requirements for delivering MPLS Services over
L3VPN - Kenji Kumaki
draft-kumaki-l3vpn-e2e-rsvp-te-reqs-02
Kenji: draft to clarify issues for e2e MPLS TE LSP over
MPLS
VPNs.
-Presented several application scenarios (see
slides)
-PEs choose correct P-TE tunnels based on
local policy
-PEs perform CAC on P-TE tunnels
-Fast protection between CEs.
-Changes from -01: added applications scenarios.
-Remaining issues: more requirements?
-Next actions_ need more comments and feedback
from
WG. Request WG to accept this as WG documents.
Ron: can we discuss it now or in mailing list?
???10: We are in middle of rechartering, so either is
ok.
Ron: show of hands: is this within charter? More yes
than no. No
clear margin so will discuss on mailing list.
Ron: thats all.
|
|
[1-3]
|
|