2006-11-06 L2VPN WG Meeting Notes Document Status review by Shane. Goals: 1) VPLS MIB 2) OAM Work ** need OAM solutions drafts ** 3) Wrap up Multicast work - need to get mcast draft refreshed, other draft are progressing In Progress: Brief overview of in-progress drafts. draft-ietf-l2vpn-radius-pe-discovery (expired) -- some intrest in room for revising and renewing this draft. ------------------- Tom Nadeau, Editor of VPLS MIB ------------------- create a MIB for both BGP and LDP Approaches to LDP draft contains: 3 SNMP MIB mocules updated from -00 based on list comments @80% addressed in the current draft. Open Items: Should MIB module be RW or RO? - who would like the writeable? Add number of attachement ckts per VSI? Add PwBindTable (contains PWs bound to VSI? Add VsiPerfTable (contains number of PWs in VSI, numberLearnedMac)? Defined: vplsOperStatus: current values are unknown, up or down. Propose adding a value of 'partialMesh'. ...continuted on slides Most pressing issues: Some are already in the IETF Bridge MIB, although they do apply, they are configurable elsewhere, so Tom does not want to include them in this MIB. These are things like enabling MAC learning, max # of MAC addr's learnable, etc. (more details on slide) Some are status object that would be good to put in. If no comments are made on these in 1 week or so, they will be left out. Next Steps: need update based on resolutions of open issues just discussed. This will be the -03 revision of this draft. Publish as a L2 VPN WG. Dave McDyson - please post slides, so we can review and comment in detail in the next 2 weeks. Tom - Yes, will do. Shane - poll of room indicated not a lot of reviewers are present. Will defer decision to make it a WG draft until after next rev. ------------------- LDP Extensions for Optimized MAC Withdrawals ------------------- Marc Lassere H-VPLS MAC withdrawal is sub-optimal. Today most implementions tend to send a Null MAC withdrawal (main mode, perhaps make this the default?). the problem with a Null MAC withdrawal is some addresses that do not need to be flushed get flushed and have to be relearned. Add a LSR ID TLV to indicate where the fault occurs, this will speed converence since only fault-relevant MACs are flushed. Next Steps: Solicit comments on l2vpn list. Ali Sajassi - asked Marc to walk through the diagram. Marc - don't have diagram here. Ali - okay, let's take to list. Marc - MAC withdraw should be sent when backup link is active. Consensus - more on list. ------------------- Signalling Standby States of PW groups in H-VPLS ------------------- Marc Lassere Related to Praveen M's draft. H-VPLS dual homing - active/standby pw status managed by MTU-s. Traffic is blocked by MTU, or prim/sec PE's forward BUM traffic to their MTU's (fast failover). the issue is that if a PE is dual homed, unknown, bcast, mcast gets forwarded by both. If traffic is loadbalanced across VSI's, some links get used concurrently, and traffic is sent w/o need. Idea here is to propose (same as Praveen M's draft) - use a PW status with a new bit defined to indicate standy/active. Could apply in a H-VPLS dual homing, or ring topologies. Benefits - use of PW grouping for scalability. Optional mechanism (trade-off between b/w usage and failover). Covered in draft: signalling standby state via LDP (RFC4447). Detailed State Machine including a/s state transitions, and notification procedures. Next Steps: Draft-muley-pwe3-redundancy also has similar ideas -- Merge?? Solicit comments on L2VPN list. Luca - Why do you need a bit? You can do this with a forwarind bit without creating a new extension. I have an implementation which uses existing bits. Pranjal - If you look at applicaiton forwarding bits - if it is in standby, and there is a fault, you have overload of the bit. Luca - when you clear the fault, you do not have to send an all-clear you can clear that one fault and keep it in forwarding. Pranjal - Clarify the existance between FAULT state and STANDBY state. Luca - would like to make it more clear in the text. You can leave the forwarding bit in different states depending on the state. Pranjal - Clear distinction between FAULT state and STANDBY state. Luca - Why? Pranjal - Because they indicate separate states in the network, and to avoid bit overloading. Luca - message mapping draft - we need to define bit usages there to clarify the needs. Mustapha - What is the forwarding bit? What we want to say to the remote node is that this pw is fine, there is no fault, but I do not want you to foeward on this. We can run normal OAM (VCCV etc.) on this pw. But, when we read 4447 it was not clear that forwarding bit could be overloaded to that end. Marc - as currently stated, we need a new bit Luca - It was intended, at least in part, to be used for any faults, if we clarify in the message mapping draft then perhaps we can just use the existing bit. ------------------- MAC Hiding in a HVPLS Environment ------------------- Ian Cowburn Problem: PE-rs learns MAC addresses for customers on its direclty attached MTUs and the remote MAC addresses for all of its configured VPLS insances. So how do you have a very scalable solution. Solution: assign an MTU-id, in control word, including source and dest identifier, switch at PE-rs based on the destination MTU ID's Benefits: extends scalability of H-VPLS, minimized additional overhead per frame (4 bytes), using standard control word through this new use. Draft coverage: signalling MAC hiding capability via LDP, action at MTUs and PE-rs, handling bcast, unknown, mcast, MTU-id specific MAC withdraw, inter- provider use Diagram on slides to demonstrate what the mechanism is doing. Ali - comments on the number of bits used. Marc - although you're using 14-bits for src and dst MAC. MTU-id's can be processed as if they are fake MACs. The processing at the PE level appears as a MAC address. Second point: n-customers could be attached via an MTU or direclty via a PE, if we were to use MAC-in-MAC it may be difficult for some hardware to handle 2 ethernet headers and MPLS Ali - a couple of comments: 32 bits is for both src and dst, you get 16k limit with 14-bits. Total # of devices is limited to this. You could exceed this interprovider. Marc - actually this limit is PER-SP, not for the total space. Ali - The price is re-mapping at SP edges. The objective is not learning UPE MAC addresses at the PE -- instead use "distributed VPLS" and at the edge, translate the label at the edge using the same. Marc - I haven't seen deployments of D-VPLS Ali - it is in the draft. Marc - but it isn't deployed. Ali - Doesn't this do the same thing? Marc - SP's can manage this internal to themselves. Shane - take to list. Sasha Vainshtein - This prevents the use of preferred control word to support pw fragmentation, that allows a single customer frame to be carried in separate packets, with this control word you cannot do this. How important is this? Don't know, but should be taken into account. Ian - this applies only to ethernet framing. Stewart - applies to path MTU. Sasha - If there is a large MTU. Marc - yes, this depends on underling jumbo frame support. Stewart - should use existing control words. Looks a bit like "MAC nicknaming" which is something that is going on in trill. So we will want to coordinate with those folks. Next Steps: - solicit comments on the list.