From l2vpn-bounces@ietf.org Mon Jan 07 12:50:23 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw77-0006Ur-NW; Mon, 07 Jan 2008 12:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JBw75-0006U8-JS; Mon, 07 Jan 2008 12:50:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JBw73-00042z-3P; Mon, 07 Jan 2008 12:50:15 -0500 X-IronPort-AV: E=Sophos;i="4.24,254,1196636400"; d="scan'208";a="2360078" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 07 Jan 2008 18:50:12 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m07HoBgJ020969; Mon, 7 Jan 2008 18:50:11 +0100 Received: from stewart-bryants-computer.local (ams3-vpn-dhcp1143.cisco.com [10.61.68.119]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m07HoABF028650; Mon, 7 Jan 2008 17:50:10 GMT Message-ID: <47826651.9000805@cisco.com> Date: Mon, 07 Jan 2008 17:50:09 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 , mpls@ietf.org, l2vpn@ietf.org, t-mpls-dt@testbed.se Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2952; t=1199728211; x=1200592211; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Liaison=20from=20ITU-T=20Q9/15=20on=20T-MPLS=20 ring=20protection. |Sender:=20; bh=6rU15ISx/A3KAd1kzIgmIVd/TcRjynVvECqFX9drQ7I=; b=kDnOHwRpLnmohXCIKQZjPxknkisNGt9IY7y6tbS66z+JrfGwWV+YMWB4zE fAQXiu1lNhc1hehrliNusL21AXuzCCUG2k5flRAYMi+qV46Gb7np/0lWpeOh 5KjAZNO5vf; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Jean Philippe Vasseur Subject: Liaison from ITU-T Q9/15 on T-MPLS ring protection. X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org We received a liasion from ITU-T Q9/15 on T-MPLS ring protection. https://datatracker.ietf.org/liaison/386/ Please can I have your views by 22 January so that we can respond to the liaison. Thanks Stewart My thoughts are as follows: This is clearly a new type of MPLS packet forwarding technology and as such comes under the purview of the MPLS Change Process (RFC 4929). It should therefore be pursued through the IETF Standards Process. It is regrettable that a new, specialist repair mechanism is proposed for this topology, when it is clear that the problem could be solved by the widely deployed repair mechanism based on nested MPLS encapsulation (so called MPLS-TE fast reroute). It is our understanding that ring protection requires signaling between the two sides of the failure before the repair can start and that this would seem to be therefore slower than the already deployed mechanism that allows the repairing system to autonomously invoke the repair. We are further concerned that unlike existing MPLS fast re-route mechanisms it is not possible to test the repair path without causing disruption to the operation of the ring. We are concerned that this mechanism will require two labels for every T-MPLS path through the network and hence does not scale as well as an encapsulation based protection. Then I have some detailed comments: In Section 7 Para 5 you say: Hold-off time: to avoid protection switching cascade in different network layers when a lower layer network protection mechanism is activated in conjunction with the T-MPLS layer protection scheme. Usage of hold-off timers allows the lower layer to restore working traffic before the T-MPLS layer initiates a protection action. Please could you explain how a ring "knows" its current level in the heirarchy in order to set the hold-off timer correctly and what impact this has on the 50ms requirement? In Section 7 para 8 you say: a) The switching protocol shall be able to accommodate as a minimum up to 127 nodes on a ring. It might be better to express this in terms of a reminder that the maximum number of hops that a T-MPLS packet can traverse - including any backtracking needed for repair is 255. In Section 18 Label assignment you say In the T-MPLS Shared Protection Ring no restrictions are applied to the labels allocation along the normal and protection connections (besides T-MPLS per platform and per interface label space requirements as described in appendix III/G.8110.1). However, at every node there must be a deterministic relation between the labels assigned for normal and protection connection in both West and East directions. Please confirm that you mean that it must be possible to associate the normal protection labels, but that the labels may be independently assigned using local policy in the ring nodes. From l2vpn-bounces@ietf.org Mon Jan 28 18:19:38 2008 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJdGE-0002h3-GL; Mon, 28 Jan 2008 18:19:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JJdGD-0002Yy-9B for l2vpn@ietf.org; Mon, 28 Jan 2008 18:19:29 -0500 Received: from ussc-casht-p2.extremenetworks.com ([207.179.9.62] helo=ussc-casht-p1.corp.extremenetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JJdGB-0007mF-Hg for l2vpn@ietf.org; Mon, 28 Jan 2008 18:19:29 -0500 Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Mon, 28 Jan 2008 15:19:24 -0800 From: Olen Stokes To: 'VISSERS Maarten' Date: Mon, 28 Jan 2008 15:19:24 -0800 Thread-Topic: Reference model for H-VPLS node Thread-Index: Acg8yeroZuO1utwaSeSgEbtOlXvELwABiJ6wCUXv2qA= Message-ID: <8329C86009B2F24493D76B486146769A91ADB371@USEXCHANGE.corp.extremenetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: "l2vpn@ietf.org" Subject: RE: Reference model for H-VPLS node X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: l2vpn.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: l2vpn-bounces@ietf.org Following off-line exchanges, I would like to draw attention on the mailing= list to several points raised in this thread so far. I would also like to= request comments from the list concerning these topics. The VPLS reference model described in RFC 4664 refers to an IEEE 802.1ad br= idge module. As such, this discussion involves both IETF and IEEE concepts= and terminology. The discussion points are therefore divided into IETF-ce= ntric and IEEE-centric sections. The following IETF-centric topics were raised: 1) Marteen makes the statement, "In tree-structured mode the VPLS Forwarder= has only 1 PW associated with the in/output port it has with the bridge fu= nction; it essentially becomes a null function and can be omitted" This is the critical difference between the two models shown in Figure A an= d in Figure B in my original email. In this case, I believe that Maarten's= reference model agrees with the reference model in Ali's presentation. In= this H-VPLS model, a packet from a MTU-s passes through the bridge module = in a PE-rs. 2) Maarten also makes the statement, "the set of PWs within a MPLS tunnel t= hat carry VPLS (i.e. VLAN) signals constitute a virtual bridge port." I believe that Maarten's and Ali's model differ on this point. Ali's chart= s show a "virtual bridge port" at the LAN emulation interface between the b= ridge module and the VPLS forwarders. Maarten appears to be describing a v= irtual bridge port on the other side of the VPLS forwarders. This differen= ce could potentially have significance when 802.1ag maintenance points are = discussed. Please comment on the mailing list your agreement or disagreement on these = points. These comments are needed in order to address OAM for L2VPNs using= an accepted reference model. Please remember to use IETF terminology when= ever possible. The IEEE-centric topics listed below were also raised in the attached email= . They are listed here because they may influence the IETF reference model= for a H-VPLS node. Comments are requested on these points as required in = order to reach agreement on the H-VPLS model questions presented above. a) Maarten states that "The Bridge and VPLS Forwarder functions are in term= s of 802.1Q part of the MAC Relay function." b) Maarten also states that 'For a full-mesh VPLS, the 802.1Q MAC Relay fun= ction combines the regular any-to-any MAC forwarding within the (Independen= t VLAN Learning (IVL) mode) VLAN with the "Asymmetric-VLANs in SVL mode".' c) The above points demonstrate a need to understand where in a 802.1ad nod= e is the location of the emulated LAN interface shown in Figure 3 of RFC 46= 64. Cheers, Olen -----Original Message----- From: VISSERS Maarten [mailto:Maarten.Vissers@alcatel-lucent.de] Sent: Wednesday, December 12, 2007 12:24 PM To: Olen Stokes Cc: l2vpn@ietf.org Subject: RE: Reference model for H-VPLS node Olen, I made the following reference model for this figure 2, assuming the there are VPLSs between the MTU and the PE-rs. I have included all PW's that terminate in the PE1-rs and PE3-rs nodes; i.e. also PW-12 and PW-23. PW-23-| |-PW-12 | |--- PW-1 ---| ||- PW-13 -|| |--- PW-3 ---| Emulated | | || || | | LAN | | || || | | ..................................................................... . | | || || | | . . |-------|-----| |---|----||---| |---||----|---| |-----|-------| . . | ----------- | | ----- ----- | | ----- ----- | | ----------- | . . | VPLS | | VPLS| |VPLS | | VPLS| |VPLS | | VPLS | . . | Forwarder | | Fwdr| |Fwdr | | Fwdr| |Fwdr | | Forwarder | . . | -----|----- | | --|-- --|-- | | --|-- --|-- | | -----|----- | . ..|.................................................|................ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -----|----- | | --|-----|-- | | --|-----|-- | | -----|----- | | | | | | | | | | | | | | | | | | | Bridge | | | | Bridge | | | | Bridge | | | | Bridge | | | | | | | | | | | | | | | | | | MTU1-s PE1-rs PE3-rs MTU3-s FIGURE A In your model, you assume that there are no VPLSs present between MTU and PE-rs. This would then result in the following model (Figure B), in which also the PW-12 and PW-23 are included. PW-23-| |-PW-12 | |--- PW-1 ---| ||- PW-13 -|| |--- PW-3 ---| Emulated | | || || | | LAN | | || || | | ..................................................................... . | | || || | | . . |-------|-----| |---|----||---| |---||----|---| |-----|-------| . . | | | | | ----- | | ----- | | | | | . . | | | | | |VPLS | | VPLS| | | | | | . . | | | | | |Fwdr | | Fwdr| | | | | | . . | | | | | --|-- | | --|-- | | | | | . ..|.................................................|................ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------|---- | | --|-----|-- | | --|-----|-- | | ----|------ | | | | | | | | | | | | | | | | | | | Bridge | | | | Bridge | | | | Bridge | | | | Bridge | | | | | | | | | | | | | | | | | | MTU1-s PE1-rs PE3-rs MTU3-s FIGURE B The Bridge and VPLS Forwarder functions are in terms of 802.1Q part of the MAC Relay function. We have to consider now the different VPLS modes: tree-structured and full-mesh. In tree-structured mode the VPLS Forwarder has only 1 PW associated with the in/output port it has with the bridge function; it essentially becomes a null function and can be omitted, as is done in the case of PW-1 and PW-3. In full-mesh mode the VPLS Forwarder provides a split-horizon functionality, which is similar to the MAC Relay functionality specified for "Asymmetric-VLANs in Shared VLAN Learning (SVL) mode" as specified in clause B.1.3/802.1Q. For a full-mesh VPLS, the 802.1Q MAC Relay function combines the regular any-to-any MAC forwarding within the (Independent VLAN Learning (IVL) mode) VLAN with the "Asymmetric-VLANs in SVL mode". I.e. some of the ports of the VLAN on this MAC RElay (encompassing the bridge and VPLS Forwarder functionality) are more special (split-horizon) than other ports of the VLAN. >From an 802.1Q/ag perspective, this will then result in the following location of Ethernet MEPs and MIPs (see Figure C), assuming that the MTU-s's have a MEP at MD Level 4. Consequently, the Ethernet MIPs that are located between the PW and Bridge (PW-1, PW-3), or the PW and the VPLS Forwarder (PW-12,PW-13,PW-23) are also having MD Level 4. PW-23-| |-PW-12 | |--- PW-1 ---| ||- PW-13 -|| |--- PW-3 ---| Emulated | | || || | | LAN | | || || | | ..................................................................... . |-------|-----| |---|----||---| |---||----|---| |-----|-------| . | MIP X MD | |MD X MIPXX MD| |MD XXMIP X MD| | MIP X MD | | | L4 | |L4 | || L4| |L4 || | L4| | | L4 | | | | | | || | | || | | | | | . | | | | | || | | || | | | | | . . | | | | | ----- | | ----- | | | | | . . | | | | | |VPLS | | VPLS| | | | | | . . | | | | | |Fwdr | | Fwdr| | | | | | . . | | | | | --|-- | | --|-- | | | | | . ..|.................................................|................ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -----|----- | | --|-----|-- | | --|-----|-- | | -----|----- | | | | | | | | | | | | | | | | | | | Bridge | | | | Bridge | | | | Bridge | | | | Bridge | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |MEP X MD | | | | | | | | | | | |MEP X MD | | | | | L4 | | | | | | | | | | | | | L4 | | MTU-1s PE1-rs PE3-rs MTU-3s FIGURE C >From an 802.1Q perspective, the set of PWs within a MPLS tunnel that carry VPLS (i.e. VLAN) signals constitute a virtual bridge port. Such virtual bridge port has an 802.1Q EISS SAP with the VPLS Forwarder fucntion (as it is part of the MAC Relay). Over this EISS SAP flows EM_UNITDATA.indication and EM_UNITDATA.request information. The endpoint of the set of PWs provide from an 802.1Q perspective a "support of the EISS" function. Such function adds in a pure 802.1Q environment a VLAN Tag or a Backbone Service Instance Tag, while in the hybrid 802.1Q/MPLS environment it adds a PW label to carry the EM_UNITDATA.request information over the MPLS tunnel. In this model, the MPLS PW label stack entry provides from the viewpoint of the 802.1Q environment a Tag which has a 20-bit "vlan identifier" (to carry the EM_UNITDATA.request.vlan_identifier parameter information) and a 3-bit "priority code point" (to carry the EM_UNITDATA.request.priority and EM_UNITDATA.request.drop_eligible parameter information. From the MPLS environment viewpoint, the PW label provides a 20-bit label and a 3-bit EXP field carrying PHB information. In this model, the VPLS looks from the 802.1Q viewpoint a VLAN with a "MPLS Label Stack Entry based VLAN Tag" (i.e. an "M-VLAN Tag" or "M-Tag"). As the PW label value for every PW in the VPLS may be different, and as the PW label value between MTU-s and PE-rs may be different, the 802.1Q equivalent model of the VPLS contains a "VID Translation Table" function as specified in 802.1ad. In this model, the MPLS tunnels provide point-to-point virtual interface ports between MAC Relay functions. ---------------- There is a second 802.1Q equivalent model possible for VPLS. In this model each PW endpoint provides a virtual bridge port supporting a single (untagged) VLAN. The interconnect between the PW endpoint and the VPLS Forwarder/Bridge function is then an ISS SAP and M_UNITDATA.request and M_UNITDATA.indication information is passed over it. The 1-to-1 nature of the VLAN-PW relationship allows to carry the VLAN untagged. In such case the M_UNITDATA.request.priority and M_UNITDATA.request.drop_eligible information is either dropped (no means to carry it), or is carried via the PW label (note that in this case the PW label is not longer performing the "M-Tag" function). It is obvious that the number of virtual bridge ports in this second model will be much larger than in the first model. From the 802.1Q environment viewpoint there will now be many parallel virtual links between two adjacent MAC Relay functions. This seems more complex then the first model. Regards, Maarten -------- Originele bericht -------- Onderwerp: Reference model for H-VPLS node Datum: Wed, 12 Dec 2007 06:12:42 -0800 Van: Olen Stokes Aan: l2vpn@ietf.org There was significant discussion at the last IETF about the correct reference model to be used when discussing OAM for a H-VPLS node. For the H-VPLS network in Figure 2 of draft-stokes-l2vpn-cfm-vccv-oam-00.txt, the reference model described in that draft is shown below in Figure A: |--- PW-1 ----| |--- PW-13 ----| |---- PW-3 ----| Emulated | | | | | | LAN | | | | | | .................................................................... . | | | | | | . .|-------|-----| |----|--|-----| |-----|--|----| |------|------|. .| ----------- | | ----------- | | ----------- | | ----------- |. .| VPLS | | VPLS | | VPLS | | VPLS |. .| Forwarder | | Forwarder | | Forwarder | | Forwarder |. .| ------|---- | | -----|----- | | -----|----- | | -----|----- |. .|.............|..|................|................................ | | | | | | | | | | | | | | | | | | | | | |------|------| | ------|---- | | -----|----- | | -----|----- | | -----|----- | | | | | | | | | | | | | | | | | | | Bridge | | | | Bridge | | | | Bridge | | | | Bridge | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ---|------- | | ----------- | | ----------- | | -------|--- | |----|--------| |-------------| |-------------| |--------|----| | | | | CE-1 CE-3 MTU1-s PE1-rs PE3-rs MTU3-s Figure A: H-VPLS node using only VPLS Forwarder connections An alternative model based on http://www3.ietf.org/proceedings/04nov/slides/l2vpn-9.pdf is shown below in Figure B: |--- PW-13 ----| Emulated | | LAN | | .................................... . | | . . |-------|-----| |-----|-------| . . | ----------- | | ----------- | . . | VPLS | | VPLS | . . | Forwarder | | Forwarder | . . | -----|----- | | -----|----- | . ..|................|................ | | | | | | |-------------| | | | | | | |-------------| | ----------- | | -----|----- | | -----|----- | | ----------- | | | | | | | | | | | | | | | | | | | Bridge | | | | Bridge | | | | Bridge | | | | Bridge | | | | | | | | | | | | | | | | | | | | | * | | | | * | | | | * | | | | * | | | | ---|---|--- | | -----|----- | | -----|----- | | ---|---|--- | |----|---|----| |------|------| |------|------| |----|---|----| | | | | | | | |---- PW-1 ----| |----- PW-3 ---| | CE-1 CE-3 MTU1-s PE1-rs PE3-rs MTU3-s Note: "*" =3D emulated bridge port Figure B: H-VPLS node using emulated bridge port connections Please note that Figure B is my interpretation of Ali's charts from his November, 2004 presentation. There are definite implications based on the differences of the two models. The VPLS forwarder only model in Figure A treats a H-VPLS network with PW access the same as a simple full mesh VPLS network. The bridge model sees a single emulated LAN interface to the (H)VPLS network and therefore is not concerned with the structure of that (H)VPLS network. The emulated bridge port model treats a H-VPLS network with PW access the same as a H-VPLS network with Ethernet access. In effect, it "separates" the network into a full mesh VPLS emulated LAN and individual access networks that can be PW or Ethernet. This "separation" is a result of the presence of the bridge module between these connections. One difference from an OAM perspective is that the emulated bridge port model allows 802.1ag MPs to be associated with PW access connections such as PW-1 in Figure B above. There may be implications to other protocols such as spanning tree. In the emulated bridge port model, PW-1 is seen by the bridge module and could be considered separately should the bridge module in PE1-rs participate in spanning tree. However, in the VPLS forwarder only model, only the single emulated LAN would be included in spanning tree. As I said during the L2 VPN meeting, I believe that choosing the correct reference model is a decision to be made by the working group. Therefore, please use the mailing list to state your views on the correct reference model to be used for a H-VPLS node. Cheers, Olen