IETF 64: Layer 2 Virtual Private Network WG (l2vpn) Meeting Minutes
Monday, November 7, 1300-1500
=============================
I) Administrivia
II) WG Document Status (Vach)
WG Doc Status:
+ draft-ietf-l2vpn-requirements-05
- Only minor changes to fix id-nits, in IESG Queue
+ draft-ietf-l2vpn-l2-framework-05
- RFC-Editor: Blocked on reqmt's
+ draft-ietf-l2vpn-vpls-bgp
- GenArt review asked for some changes, to align with VPLS-LDP.
Changes agreed upon; should be done shortly after IETF 64.
+ draft-ietf-l2vpn-vpls-ldp
- GenArt review asked for some minor changes; changes agreed upon,
should be sent out soon.
+ draft-ietf-l2vpn-ipls-05
- WG Last Call after IETF 64
+ draft-ietf-l2vpn-arp-mediation-04
- WG Last Call after IETF 64
+ draft-ietf-l2vpn-signaling-06
- WG Last Call completed, WG chair analysis done, sent to Mark;
Mark to proccess & shepherd through IESG.
+ draft-ietf-l2vpn-radius-pe-discovery
- Needs more work, esp. views from SP's.
+ draft-ietf-l2vpn-oam-req-frmk
- Dinesh to present changes -03 -> -04 at this meeting
3 New WG Docs:
+ draft-ietf-l2vpn-vpws-iw-oam-00
- Been around a long time; probably ready for WG Last Call.
+ draft-ietf-l2vpn-vpls-mcast-reqts-00
- Fairly new WG draft, but borrows from mcast work in L3VPN with
mods to work in L2VPN, so quite mature already. Good response on
it, lots of SP work also. Should be going to WG Last Call
fairly soon.
+ draft-raggarwa-l2vpn-vpls-mcast-01
- After IETF 64, will be republished as WG Draft. ID is about
methods/procedures to create mcast trees in L2VPN. Discusses
encapsulation, signaling protocols, general architecture of
VPLS multicast.
- Separate drafts on PIM snooping & LDP for L2VPN mcast, (both
presented at this meeting).
III) VPLS Interoperability with CE Bridges
draft-sajassi-l2vpn-vpls-bridge-interop-02.txt
Ali Sajassi
- Overview of ID History:
+ At IETF 63 asked to partition draft into mandatory and optional
categories.
+ This new version accomodated those suggestions.
- Objectives
+ Identify issues associated with IEEE bridges as CE devices
+ Demonstrate how to use PE models from L2VPN-FR to address
majority of interop issues.
- Re-categorization
+ Mandatory Issues: service mapping of AC, CE bridge protocol
handling, partial mesh of PW, multicast.
+ Optional Issues: customer network topo changes, redundancy
and dual-homing, MAC address scalability, ease of interop
with Provider Bridges.
- VPLS PE Model as defined in L2VPN Framework
+ What if multipoint Ethernet service spans multiple networks
(MPLS, 802.1ad, etc.) Service is end to end, but VPLS is just
in an MPLS domain. VPN framework models a PE as a bridging
component facing the customer ACs and a LAN emulation model
facing the core (consisting of VPLS forwarders).
- VPLS PE Model as defined in L2VPN Framework
+ Bridge module can be split into C-VLAN and S-VLAN are per
802.1ad. Once you use that model it becomes clear how you can
interop with customer bridges/CE protocols and support
different mappings into VPLS.
- VPLS as (V)LAN Emulation
+ For a given VPLS instance LAN emulation is done by VPLS forwarders
with full mesh of PWs, and mapping into bridge module.
- Questions: Any section needs clarification? Authors prefer to hear
it on the list to clear it up.
- Given that this is based on L2VPN framework model and elaborated
upon it to get L2VPN working then is consistent with work here in
L2VPN, so therefore can we move to WG status?
Q&A at the Mic:
* Himanshu Shah - how is topology change notification from customer STP
sent to VPLS so you can do MAC withdraw?
* Ali - draft documents two ways. (1) customer TCN can be mapped to IEEE
provider bridge TCN - message generated per customer with a special MAC
address that when it goes to specific nodes tells them to flush the
MACs for that VLAN. (2) use LDP MAC withdraw message. If you do that
then you need to interop with provider bridges. => first way has no
interop issues, second way does.
* Florin Balus - looking at picture. Should each forwarder be modelled
as a port in the bridge (rather than muxing to the bridging module)?
* Ali - discussed on mailing list. VPLS forwarder does MAC learning per
PW. That whole set of PWs can map to a virtual interface in the
bridging module - where each VPLS maps to a VLAN.
* Florin - so each forwarder is a bridge?
* Ali - IEEE bridge is data plane plus control plane. With this model
the VPLS forwarder is a MAC filtering database. Doesn't mean that you
can't *implement* it in one filtering database.
* Shane - will send out mail after meeting to check consensus on moving
to WG status. Please look out for that.
* Ali - final note, would like to recommend reading of the L2VPN
framework so you can get an idea of how this solution maps to that
framework.
IV) Requirements for Multicast Support in Virtual Private LAN Services
draft-ietf-l2vpn-vpls-mcast-reqts-00.txt
Yuji Kamite
- Draft covers problem statement and shows specific functional reqs
for solutions. Initially published in June, but incorporates a lot
of info from L3VPN. Major issues resolved in Sep 2005 issue. Now
a WG doc.
- Major changes:
1) "Traffic Tax". What is the weight of the two issues of (a)
replication to non-member sites (b) multiple copies on one shared
physical path. Solution - SHOULD try to solve both issues, but
MUST identify which issues it tries to solve and SHOULD provide a
basis for evaluating how well it solves the issues (if it's
approximate).
2) IGMP snooping. IGMPv2 vs v3. Refers to MAGMA-SNOOP.
3) L2 Processing - Corrected statement of L2 processing; no reason
to rule out L2 techniques, (CGMP, GMRP, etc.)
4) IPv6 issue raised at last IETF - conclusion was no changes needed
as MLD snooping was already mentioned and NDP will also work,
(see comment on list: Aug 19 2005).
- Editorial changes etc.
- Next Steps
1) Need to clarify remaining issues, (e.g. application
considerations, how to flood L2 control frames (BPDU), what
protocols to snoop (PE-CE), protection/restoration wrt PIM hello
snooping).
2) Need more feedback on the OAM section (6.5) from implementors and
operators. Please send comments to list.
Q&A at the Mic:
* Ijsbrand Wijnands (?) - this doc covers IP and L2 (control plane)
multicast. Why include L2 packets - they're already broadcast? If we
limit scope to L3 then solution will be easier.
* Yuji - Main idea is to optimise L3 multicast over VPLS, but it must
also consider how to deal with L2 frames which use multicast MACs.
Required that solution has an optimization for L3 data but also carries
L2 control frames in a way that doesn't cause operational (or other)
issues. So trying to show what the potential issues are.
* Yakov Rekhter - Agreed to previous comment. It's best to document IP
multicast over VPLS and *then* document L2 or whatever else is left.
Much more benefit to addressing former than addressing latter.
V) PIM Snooping over VPLS
draft-hemige-serbest-l2vpn-vpls-pim-snooping-00.txt
Venu Hemige
- At last IETF, consensus of WG was to split VPLS multicast into
4 components:
1) How to build mcast trees, (Rahul's draft)
2) IGMP snooping (in magma)
3) PIM snooping in VPLS, (this draft)
4) PE-PE mcast state distribution (LDP or BGP) -- to prevent
snooping on PWs
- Therefore, draft-serbest split into two drafts: this one and
the LDP one.
- PIM Snooping in VPLS: In VPLS multicast traffic is flooded to all
ports, (whether they want to receive it or not). PIM snooping
prevents unwanted traffic going to ports that don't want it, (Issue
A of Reqmt's Draft). PIM snooping on ACs. Forwarding rules for when
IGMP and PIM are both active. Requires PIM join supression to be
disabled, (to keep it clean). Can use either PIM snooping on PWs or
LDP to distribute state info.
* Ali - Question on PIM snooping vs. LDP. Venu - Either/or can be used.
- Changes from draft-serbest. Removed IGMP snooping; updates on PIM
snooping procedures; requires CE's to disable PIM Join suppression;
PIM join/prune are flooded in VPLS; LDP procedures to
draft-qiu-serbest-mcast-ldp; modified procedures for duplicate
traffic -- new procedures use control plane, scales better, no
data plane requirement.
- PIM snooping basic example: Joins directed to RPF neighbor, but
flooded so seen by other PE's and CE's. Only PE's on the path to
the RPF neighbor build state. New procedures in control plane to
prevent duplicates, (scales solution better).
- Assert mechanism to prevent duplicate traffic. VPLS split horizon
rules dictate that traffic ingress on PW should not egress on
it. But want to allow traffic on any port to reach a router that
forwards traffic onto a VPLS instance, result in assert between
rtrs. New rules: (1) add incoming port to outgoing port list; and,
(2) when an upstream PE sees a join it adds PW towards RPF neighbor
to the outgoing port list. This allows the assert to happen and to
avoid duplicates.
- PIM snooping is needed to make VPLS multicast work. Lots of
interest in solving this issue. Can it be WG?
Q&A at the Mic:
* Dino Farinacci - In PIM, join supression was there to enable scaling
over Ethernet. Why would disabling it globally help you scale?
* Venu - Part of the problem is that if you don't disable join supression
then VPLS won't work.
* Dino - I know why you did it, and I know you want it to make things
work. But it won't work if you disable it either.
* Yakov - this is about tradeoffs. Not black-and-white. If you want to
restrict traffic to PEs that want it then you have more joins. But if
you don't then you flood. So it's a tradeoff. A solution should allow
for the tradeoff and identify them.
* Ijsbrand - You can make it work without disabling join supression.
* Venu - Yes, that was presented in earlier draft at last IETF, but it
was deemed that those were 'hacks'.
* Ijsbrand - just an issue of how you define PIM snooping. If you want
this to interoperate you need to decide whether to allow/disallow
supression. I'd rather prefer Join suppression and let the PE router,
(i.e. the entity that does PIM snooping), do the right thing. Maybe
the draft should not explicitly require disabling Join suppression on
the CE routers, so we don't have to change their behavior.
* Ali - have you discussed getting feedback from PIM or MPLS WG as to
using LDP for passing PIM messages?
* Venu - No.
* Ali - Would be good to get it.
* Venu - We will do that.
* Suresh - Is disabling join supression an option or a requirement?
* Ijsbrand - If the CE wants to disable join supression then go ahead,
but the requirement here shouldn't require it. The draft assumes that
PIM snooping is both edge/core functionality. Not necessarily the right
thing to include the core - as there are other ways of building the
trees. Should core/edge be separated into two drafts?
* Venu - Rahul's draft addresses how to build trees in core. When we
talk about LDP we're talking about VPLS join information.
* Suresh - Some history/perspective of Join-Suppression Issue. When
this draft was presented last time we didn't want to disable join
supression, but it requires the PE's to participate more than just
snooping. By requiring Join Suppression, PEs just snoop - no packets
have to be modified. Without Join Suppression, the PE would
become an active element in the network, (not just a snooping device).
* Tom Morin - About Join Suppression issue on PE's. Would it work also
if you use different tunnelling for multicast, (e.g. P2MP tunnels)?
* Venu - Yes. We have talked to Rahul to make sure we're on the same
page. Please point out any discrepancies.
* Tom Morin - Some parts of draft are repeats of reqmt's doc. It maybe
best to strip them out.
* Venu - OK, will talk to you about that...
* Venu - Asked if this could become a WG document?
* Shane (Chair) - We will take it to the list, to iron out whether we
want or don't want Join Suppression in the ID.
VI) Using LDP for VPLS Multicast
draft-qiu-serbest-l2vpn-vpls-mcast-ldp-00.txt
Ray Qiu
- LDP already used to establish PWs and we don't want new protocol;
Good to use LDP as runs over TCP -- no state refresh, so it scales;
No need to send state to all PE routers (if PE has no listeners?);
therefore, LDP is good.
- Only snoop on ACs, so it scales well. C-multicast control packets
are forwarded "as is," based on destination MAC address. Therefore,
we don't modify packets.
- New LDP Mulcast Capability TLV, carried in LDP initialisation
message to do capability discovery. Another TLV in notification
message with various sub-TLVs. Will modify PIM Hello sub-TLV in
next revision of draft, (MAC address isn't needed -- had thought it
was required in corner cases).
- PE floods Joins upstream, but also sends LDP messages, to build
PIM neighbor states. LDP also used to build Join/Prune state.
- Next steps: Questions? WG document?
Q&A at the Mic:
* Dino - You need explicit tracking in LDP to make this work, LDP doesn't
have that concept today. When you send Join's from multiple receiver
PE's, you need to keep track of them so you know when to Prune.
* Ray - encoding here is aligned with PIM state. State machine is in the
PIM snooping spec. Don't think anything needed for LDP.
* Suresh - PE downstream that has CE receivers is the one which
accumulates Joins.
* Dino - Fanout from the ingress PE requires you to know when each one
has stopped listening.
* Suresh - It's a per-peer thing. 2 diff PEs on 2 diff sessions.
* Dino - that's explicit tracking.
* Venu - no need for explicit tracking in LDP. It's needed in the
snooping component. PIM keeps state as to where it receives the Join.
don't need to change anything in LDP.
* Dino - Absolutely right. Now we have explicit tracking in 3 protocols.
* Venu - You need some entity to gather info/state. There's no protocol
involved. PE's snoop - they don't run PIM...
* Ali - before we consider this as WG doc, we should take this to the PIM
and MPLS WGs before we overload LDP.
* Albert Tian - This is using LDP to carry multicast routing info. People
know that PIM refresh reduction is being worked on in the PIM group.
TCP as a reliable transport makes PIM work quite similarly to this, it
could be a viable solution to this.
* Yakov - 2 comments: 1) Overloading is a red herring. We've done it with
BGP & LDP. LDP was designed for unicast labels, then it was extended
from IP FECs to PWs and nobody complained. Why now? 2) Putting PIM
over TCP. If it happens we can evaluate it. Until then this is our
only option.
* Shane - Check on how many in favour/against/have even read the draft.
3 in favour. More against. 12 or so read it. Take to list and iron out
the issues.
VII) L2VPN OAM Requirements and Framework
draft-ietf-l2vpn-oam-req-frmk-04.txt
Dinesh Mohan
- L2VPN OAM. Draft introduces a framework so we can address how OAM is
applied in different parts of the network. Points out the native
mechanisms that can be applied and also what impact this has on the
PSN layer, (specifically the OAM mechanisms across that). Service
layer to make use of native technology OAM. Underlying PSN layers
make use of PW/LSP OAM.
- Draft-04 Editorial Updates: Addt'l authors, contributors added
(mainly SP's). Section 1.1 (Terminology) added. Section 4
reorganized and other sections added for better readability,
specifically: distinguishing VPLS and VPWS OAM. VPWS aspects
consolidated into this draft.
- Technical Updates: Section 3.2, on OAM domains, clarified -- needed
to draw distinction between hierarchical and adjacent domains. At
least in PWE3 there is now MS-PW. Section 5 added to discuss VPWS
framework, based on draft-delord-pwe3-oam. Added section 9, OAM
operational scenarios, to provide info on what mechanisms can be
used for different OAM layers, but not prescriptive.
- Two models in which VPWS services can be managed:
1) CE owned by customer. Access network is physical interface from
CE-PE, so not much OAM to be done on AC, and monitoring is shared
between SP and customer. SP monitors the PW.
2) CE managed by SP. SP has end-to-end manageability, therefore runs
end-to-end OAM. Two sub-models, depending on whether PE's are client
service aware. If AC is an access network the SP needs to monitor
that, and again there will be an underlying tunnel layer that
provides the AC PW.
- Technical Updates:
+ Added an Appendix on alternate management models, specifically
around scenarios where the PE can't do the native service OAM.
+ IPLS OAM Sections removed, no interest or contributions.
- Alernate Mgmt Models:
1) Minimal OAM. Model where provider does end-to-end OAM. Operators
monitor segments, eg.: Access Tunnels & PSN Tunnels. Issue is that
it's hard to localise a fault if the service is down.
2) Segment OAM with I/W. Interworking is required on PE, which may
be simple or complex, depending on homogeneous or heterogenous
VPWS. Issue is that it isn't true end-to-end OAM. Lots of
variations of the Interworking Function need to be realised.
- Next Steps:
1) Need to add the VPWS OAM, (based on the delord draft). Will add
a section after this meeting.
2) Need to update some refs.
3) Targetting Last Call by the next meeting, (would have done it
this meeting if the above 2 issues were addressed in time).
4) Initiate some solution drafts. May amount to just highlighting
how existing mechanisms in PWE3 and L2VPN can be used in
conjunction with the native service OAM.
5) Also can initiate draft on interim reqmt's, (minimal OAM
solutions), but would need volunteers to author this.
Q&A at the Mic:
* Vach - I am confused as to what direction you're taking. One sense is
we do native OAM based on AC, (e.g.: ATM PW). Are you suggesting that
native OAM is not sufficient? Is the draft suggesting that IW is not
required at all?
* Dinesh - Draft provides framework on how end-to-end service monitoring
can be exercised. One option is to apply native OAM for end-to-end
service OAM. If end-to-end service monitoring is not sufficient with
native mechanisms, then we can do some sort of interworking. How this
is used in terms of a solution is that each solution can discuss which
model it is using and what requirements it meets.
* Himanshu - Just to be clear, are you proposing that for Ethernet OAM
(where IEEE are working on OAM) that a VPLS PE should do something
specific on the PW?
* Dinesh - the point is that you can monitor at service layer
(e.g. Ethernet OAM) depending on whether the PE has the capability to
do it or not. This draft only gives an overview of the full picture.
The solution drafts, in the future, can show how it works.
* Chair - Does anybody have any other comments on this draft?
* Himanshu - Want to go back to multicast. Would like to know if
multicast pruning is required or not. Is that the issue or is LDP
not required?
* Ali - can you take to mailing list? Going back to L2VPN framework.
Since it now has hierarchical and peer models it is very inclusive so
think it is ready for Last Call. Please read and make comments on the
mailing list.
* Shane - when will you have a final draft?
* Ali - January? Have thanksgiving then vacation etc.
* Dinesh - would second that.
* Shane - be prepared to read this in Jan so it can be ready to Last Call
(perhaps) by next IETF.
* No more comments, meeting adjourned.
VIII) Meeting Closes
|