New Ring Protection draft

I may be missing somet= hing important, but how iy seems that you ignore the fundamental diffe= rences between Ethernet and MPLS data planes in your analysis.<= /div>

Ethernet data plane&nb= sp;inherently recognizes "well-know multicast MAC destination addresse= s". If a switch wants so, it can catch all the frames with such a DA a= nd decide how it treats them "out-of-band". All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is&nb= sp;exactly what allows separation between addressing and MEP/MIP = levels in 802.1ag. The disadvantage of this approach is that Ethernet= OAM frames are not necessarily fate-sharing with the data traffic.

The MPLS data plane is defi= ned in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331= , 5332. Its analog of Ethernet well-know multicast MAC destination add= resses is the reserved Router Alert Label. But its usage has been rejected for usage in MPLS-TP OAM exactly be= cause fate-sharing of data and OAM packets could be broken. Instead, MPLS-T= P uses two different mechanisms:

GAL. This mechanism can only be used to= address MEPs, because the LER processing a packet with the GAL at some lev= el in the label stack is not allowed to look at it unless it terminates all= the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to t= he loopback interface").
TTL expiration. This is the only mechan= ism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occ= ur in the first label stack entry following all the labels terminated by th= e supporting node.

In short, LERs do not look at the next la= bel if they do not terminate the previous one.

Hence I think that some of the MEPs you'v= e defined are non-addressable (and hence unusable) in MPLS-TP which shares = the MPLS data plane.

My 2c,

Sasha

From:= mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maar= ten Vissers [maarten.vissers@huawei.com]
Sent: Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Hi Greg,

See inline..

From: Greg Mirsky [mailto:greg= imirsky@gmail.com]
Sent: vrijdag 22 januari 2010 20:29
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you'v= e wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network = instances". I think that from the definition of MPLS Section follows that there can not be an intermediate M= PLS node on a given MPLS Section which is aware of that Section.

In your example (slide #7) nodes P and P' (to differentiate them from = left to right) of Carrier A are terminating points of MPLS Section of Carri= er A.

[maarten] Correct.

S-PEs of Carrier B are unaware of that MPLS Section. &= nbsp;

[maarten] not correct. The figure shows two MPLS-TP Section = layer MEG levels; the top level MEG has its endpoints (blue MEP functions)&= nbsp;in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and= in right S-PE and P' nodes.

[maarten] The most left and right S-PEs of carrier B te= rminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP= Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Sectio= n layer MIP function, which will process the MPLS-TP Section layer OAM from= the top MEG level.

[maarten] I have attached a slightly modified version of the= slide 7. The modification is the replacement of the 802.3 interface betwee= n carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent s= ection monitoring capabilities and it is now not necessary to instantiate t= he MPLS-TP Section layer TCM/Segment MEG level between these P and left S-P= E nodes. This is reflected by the absence of the lower blue Section MEP functions.

[maarten] On the side of the adaptation functions&= nbsp; between MPLS-TP Section layer and SDH layers (blue/grey colored = trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry h= eader" (in analogy to the priority vlan tag in ethernet). The use= of such "P-LSE" header on the MPLS-TP over SDH interface would b= e required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets pass= ed through the carrier B network; i.e. including the MPLS-TP Section OAM pa= ckets. If all Section OAM packets have the same priority/drop eligibility, = then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/dr= op eligible level to the the unlabelled (section OAM) packets.<= /span>

[maarten] For the latter case, the MPLS-= TP Section layer signal will have its section OAM equipped with GAL as BOS.= For the former case, the MPLS-TP Section layer signal will have its sectio= n OAM equipped with 'P-LSP' label as BOS and GAL as second label.

[maarten] Assume the latter case, then the blue MIP function= in the left S-PE node will process the GAL as BOS.

Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Sectio= n, none of nodes of Carrier B, including S-PEs, should bother to process th= e GAL. Doing otherwise will break client-server layering. &= nbsp;

[maarten] I understand why we were coming to different concl= usions. I hope I have clarified my view with the SDH physical media layer e= xample.

[maarten] You may now also understand why the definition of = Section layer in G.805 defines that the section layer network is concerned = with all functions which"**provide for the transfer of infomation between locations in path layer networks**.

It is this latter item that allows section layer trails to s= pan multiple physical media layer trails, and thus to have intermediate nod= es in the section layer connection.

[maarten] But in all honesty, most of the Section layer conn= ections are terminating at the same ports as their underlying physical medi= a layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that= section layer connections terminate at adjacent nodes. Someone who looks b= eyond its own network will conclude that section layer connections terminat= e in nodes that provide access to path layer signals.

That is why I can not agree that an intermediate node contains instanc= es of multiple MPLS-TP networks. I think of a node as performing its functi= ons at certain MPLS-TP network layer only.

[maarten] It is my understanding that we are missing a descr= iption which explicitly describes the mapping of labels onto layers. One MP= LS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation res= ults is too large to attach, I will email you a copy privately. I have atta= ched a summary of the results up to this point in time.

Another question is whether Carrier B sets its VC label as BOS or not,= as I understand we haven't decided yet with number of BOS in carrier's car= rier scenario. But that, to me, is separate discussion.

[maarten] I have understood that that decision has been made= . Refer to the SB10 comment "Yes. S=3D1 does not indicate the boundary between the client and server. It ind= icates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU= -T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1.

Maarten, I greatly appreciate your input and our discussion. = ;

[maarten] I appreciate your questions and discussion.=

Regards,

Maarten

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten V= issers <maarten.vissers@huawei.co= m> wrote:

Hi Greg,

The intermediate nodes contain multiple MPLS-TP (MTP) layer ne= twork instances, of which the top MTP layer is shared by carrier A and B. S= ee slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer netw= orks. In the attached ethernet-connection-concepts file you find the s= ame case illustrated also on slide 7.

Other slides illustrate other cases of carrier-carrier and cus= tomer-carrier interactions.

Note that the functional models for the MPLS-TP and Ethernet c= ases are the same; I already had the Ethernet models and have converted tho= se into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is t= he encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MP= LS-TP via a Label Stack Entry (LSE) header.

Regards,

Maarten

From: Greg Mirsky [mailto:gregimirsky@gmail.com]

Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers

Cc: mpls@ietf.org; mpls-tp@ietf.org

Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section<= br>

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of MPL= S-TP transport? But wouldn't presumed processing of client MPLS-TP section = by intermediate nodes of server MPLS-TP layer be just plain violation of se= rver-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vi= ssers <maarten.vissers@huawei.co= m> wrote:

Greg,

It is not uncommon to carry a section layer signal as a servic= e through the network of another carrier. E.g. Ethernet port based services= carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of po= rt based service would carry the MPLS section layer signal as a service thr= ough the network of another carrier. The section will now pass through inte= rmediate nodes.

Regards,

Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC = 5586 definition of the Section Layer Network and the last paragraph on sub-= section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to se= ction as server layer that provides service between adjacent nodes (my underlining). At the same time, = the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediat= e nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL.= If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate= nodes on the section (on the segment, but not on a section) at this partic= ular layer.
Your clarification is greatly appreciated.

Regards,
Greg

--_000_A3C5DF08D38B6049839A6F553B331C76BFDEB9FFEBILPTMAIL02eci_-- From maarten.vissers@huawei.com Sat Jan 23 08:03:00 2010 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C40F3A68D4; Sat, 23 Jan 2010 08:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.002 X-Spam-Level: X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3+YPPud70-m; Sat, 23 Jan 2010 08:02:56 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A18B03A68DD; Sat, 23 Jan 2010 08:02:55 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWP00F04J8GJN@szxga04-in.huawei.com>; Sun, 24 Jan 2010 00:02:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWP009B8J8GRY@szxga04-in.huawei.com>; Sun, 24 Jan 2010 00:02:40 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWP00AEPJ8FT0@szxml01-in.huawei.com>; Sun, 24 Jan 2010 00:02:40 +0800 (CST) Date: Sat, 23 Jan 2010 17:02:38 +0100 From: Maarten Vissers In-reply-to: To: 'Alexander Vainshtein' Message-id: <000001ca9c45$7c86dc90$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_NjKuAVBGGq3TqSZvtKUSKQ)" Thread-index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQA== Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jan 2010 16:03:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_NjKuAVBGGq3TqSZvtKUSKQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sasha, > In short, LERs do not look at the next label if they do not terminate the previous one. > Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane. If what you state is correct there is a serious problem within the existing draft specification for MPLS-TP. These functional models describe a part of the required functional behaviour in a (packet) transport network of any technology. I doubt that such problem exist... so the MEPs and MIPs in my models are all addressable (and hence usable) in MPLS-TP... Let's analyse the left inter domain interface between carrier A's P node and B's left S-PE node as an exercise... 1) there is a MPLS-TP Section layer transport path (VSC) between carrier A nodes P-left and P-right 2) there is a MPLS-TP Section layer transport path segment (VSC Segment) between nodes P-left and S-PE-left 3) there is a MPLS-TP transport service layer transport path (VCC) between nodes S-PE-left and S-PE-right (yellow MEPs). - The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL. - The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL. - The lower blue MEP in node S-PE-left has to process all packets with top of stack the GAL. - The blue MIP in node S-PE-left has to process all packets generated by the higher blue MEP in node P of which the TTL expires; these packets arrive at node S-PE-left with two labels, of which the bottom of stack label is the GAL and the top of stack label is a regular LSP label. - The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets; the new label value will be the value inserted by the left yellow MEP in the S-PE-left node (indicated by LSE next to the yellow MEP symbol). - If the packet was a VSC OAM packet of which the TTL expires, the packet will be extracted by the blue MIP within the VSC. - The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in the S-PE-left node (i.e. egress MIP issue applies). - The VCC signal is multiplexed into an MPLS-TP transport path layer transport path (VPC) and its packets are prepended with a new LSP label identifying the VCC. - Etc. - In the reverse direction, the VPC terminates on the right NNI port of the S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All other VCC LSP related packets are forwarded to the egress port which is connected to carrier A's P node. - The VCC LSP terminates on the egress port, and the LSP label identifying this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can now determine which packets carry the VCC LSP OAM by checking for the GAL as next top label. - The VCC LSP label is also removed from the non-VCC LSP OAM packets and it is possible that on one of those packets the TTL expires. Such packets are processed by the blue MIP function above the yellow MEP function in the S-PE-left node. - The outer label on packets of which the TTL has not expired will be swapped, and LSP OAM will be added in the lower blue section layer MEP on the S-PE-left node. This OAM will be output with GAL as top and bottom of stack label. - Etc. I can't find a problem in the above required behaviour, besides the well known egress-MIP identification problem. There is always an outer LSP label being terminated when a MEP function is following and LSP OAM has to be extracted and processed. In some cases the LSP terminates on an ingress port (DOWN MEP), in other cases the LSP terminates on an egress port (UP MEP). See inline for more comment... _____ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: zaterdag 23 januari 2010 8:57 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org; 'Greg Mirsky' Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I may be missing something important, but how iy seems that you ignore the fundamental differences between Ethernet and MPLS data planes in your analysis. [maarten] I am absolutely not ignoring the differences between Ethernet and MPLS data planes, as I am also not ignoring the commonalities. [maarten] What I mean is that it is possible to set up an e.g. 9-port mp2mp LSP connection in the MPLS technology and order an mpls switch to read the inner (PW) label and use the value of this inner label to forward the packet to one of the 9 output ports of the mp2mp LSP... It should be clear that a switch with such capability has a feature which is not described in the MPLS RFCs; i.e. it is a proprietary extension which I am describing below to illustrate that such extension does not interfere with the standardized MPLS behaviour, and that it does not change that behaviour. ----------------- [maarten] It is very simple to test the forwarding of packets in such mp2mp LSP in a research lab :-)...; inner label values 1000-1999 were delivered at output port 1, inner label values 2000-2999 were delivered at output 2, inner label values 3000-3999 were delivered at output port 3, etc. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and forwards all packets with inner label value 1xxx to output port 1, with inner label value 2xxx to output port 2, etc. [maarten] Another nice test application for such LSP is in a physical ring; e.g. with 8 nodes. In this case you can identify the destination ring node in the 3 most significant bits of the PW label and the output trib card on a ring node by the next 7 bits and the individual PW instances by the 10 least significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via its east line port and packets with inner label values 100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks between nodes 5 and 6, then ring node 0 will change the forwarding of packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port. Node 0 is informed about the break between nodes 6 and 7 by means of a ring-APS message including the number of the node and the interface (east/west) detecting the fault. Ring node 0 will always extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent that packets get looped in the mp2mp Ring-LSP and forward packets with other label values on the east line port to the west line port (and vice versa). [maarten] to support the transport of p2mp PWs through such mp2mp LSP another set of PW label values was allocated, e.g. 10000-10999. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and in case of a value in the 10xxx range looks up in a table the subset of output ports to which this packet has to be sent. [maarten] The same mpls switch also supports p2p LSPs and when the outer label value is associated with such p2p LSP it will ignore the inner label value and forward the packet to the output port. [maarten] The same mpls switch also supports p2mp LSPs and when the out label value is associated with such p2mp LSP the switch will ignore the inner label value and looks up in a table the set of output ports of this p2mp LSP and forwards the packet to all output ports. [maarten] The same mpls switch also looks at the inner label on the interface port to identify if the packet is an OAM packet and then look at the ACH channel type to identify the type of OAM packet to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; new mpls switch ports will be able to look at inner labels of all packets; this is a similar evolution as we got in ethernet... existing ethernet switches could only look at the TYPE and DA fields to identify if an OAM frame had to be processed (those switches could only support a subset of the Y.1731 OAM), new ethernet switches are looking at the TYPE and MEL fields and can support the full set of Y.1731 OAM. [maarten] I hope you understand now that it is possible to extend the MPLS data plane specified in the RFCs with a 'connectionless-LSP' capability. Such extended mpls dataplane will then contain a mix of connection oriented-LSPs and connectionless-LSPs. The behaviour of the connection-oriented-LSPs complies with the specifications in the RFCs. The connectionless-LSPs are a bonus. --------------------- [maarten] An ethernet switch reads the outer vlan identifier and when the outer vlan identifier is associated with a - p2p VLAN it will ignore the DA value and forward the frame to the output port - p2mp VLAN it will ignore the DA value and looks up in a table the set of output ports of this p2mp VLAN and forwards the frame to all those output ports - mp2mp or rmp VLAN it will read the DA and looks up in a table the output port or ports of this mp2mp VLAN to which this frame should be forwarded. The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases on the interface port to identify if the frame is an OAM frame and then look at the MEL field and OpCode fields to identify the type of OAM frame and its MEG level to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). [maarten] I don't see as such any functional difference between the mpls and ethernet data planes; the same information elements are present in both data planes, but with a different encoding of this information in the frame/packet... the main difference is that standard mpls switches don't use the inner label value to control forwarding of a packet to a subset of output ports of an LSP, while ethernet switches typically support both the use of the DA value to control forwarding and the don't use of the DA value to control forwarding to a subset of VLAN output ports... but note that there is also a set of ethernet switches that only support don't use of the DA value to control forwarding, i.e. which support only p2p and p2mp VLANs. Ethernet data plane inherently recognizes "well-know multicast MAC destination addresses". If a switch wants so, it can catch all the frames with such a DA and decide how it treats them "out-of-band". [maarten] The well-known MAC multicast destination addresses listed in Table 8-1/802.1Q are identifying management plane and control plane protocols that are carried over the links; those frames are not belonging to the user traffic carried in the VLANs. In MPLS-TP similar management and control plane information is carried via the MCC and SCC packets specified in RFC5718. [maarten] If you read G.8021 then you will notice that the well-know multicast MAC destination addresses for OAM are not being recognized in the ETH atomic functions processing Ethernet OAM. Note that G.8021 has never used the DA field in the Ethernet OAM frame as a means to identify OAM from non-OAM frames, as Y.1731 has from day one specified OAM frames that carry a unicast address which do not contain these well-known OAM multicase destination addresses. Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the MEL field to identify the MEG level and the OpCode field to identify the type of OAM. [maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from non-LSP OAM packets, the label stack to identify the MEG level and the ACH channel type field to identify the type of OAM. I.e. the same information, just a different encoding. All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is exactly what allows separation between addressing and MEP/MIP levels in 802.1ag. [maarten] As indicated above, your understanding of Ethernet OAM protocol processing does not align with Y.1731/G.8021 specifications. [maarten] The unicast LBM OAM is a special OAM frame/packet as it requires one additional information element; i.e. a MIP identifier. This MIP identifier must be carried in the LBM OAM frame/packet in both Ethernet and in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in a bidirectional p2mp LSP located at the same hop count from the MEP. Because the bidir p2mp LSP was only recently described in this mailinglist the implications of such LSP on the loopback OAM have not yet been investigated and documented. [maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP identifier field when the OAM frame/packet is identified as a LBM OAM. The MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the OAM framework. But if there is a real demand for such bidir p2mp LSP or PW, we should include the MIP Identifier in the OAM framework document for loopback OAM. The disadvantage of this approach is that Ethernet OAM frames are not necessarily fate-sharing with the data traffic. [maarten] All Ethernet OAM frames fate share with the VLAN (i.e. the Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets will fate share with the PW and LSP (i.e. the MPLS transport entities). [maarten] There is one type of OAM that has to fate share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both the VLAN/PW/LSP and the frames/packets for which the ingress count is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs there is a problem to meet the second requirement. I.e. no difference as such between Ethernet and MPLS. The MPLS data plane is defined in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet well-know multicast MAC destination addresses is the reserved Router Alert Label. But its usage has been rejected for usage in MPLS-TP OAM exactly because fate-sharing of data and OAM packets could be broken. Instead, MPLS-TP uses two different mechanisms: 1. GAL. This mechanism can only be used to address MEPs, because the LER processing a packet with the GAL at some level in the label stack is not allowed to look at it unless it terminates all the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to the loopback interface"). [maarten] The ethernet equivalent to the GAL is the OAM ethertype value 89-02. 2. TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in the first label stack entry following all the labels terminated by the supporting node. [maarten] As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it will have to include the MIP Identifier to address the MIP that has to perform the loopback. [maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry management plane frames. This is similar to the MPLS-TP MCC OAM packet defined in RFC5718. Regards, Maarten In short, LERs do not look at the next label if they do not terminate the previous one. Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane. My 2c, Sasha _____ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers [maarten.vissers@huawei.com] Sent: Saturday, January 23, 2010 7:37 AM To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Hi Greg, See inline.. _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 20:29 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section. In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A. [maarten] Correct. S-PEs of Carrier B are unaware of that MPLS Section. [maarten] not correct. The figure shows two MPLS-TP Section layer MEG levels; the top level MEG has its endpoints (blue MEP functions) in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and in right S-PE and P' nodes. [maarten] The most left and right S-PEs of carrier B terminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP Section layer OAM from the top MEG level. [maarten] I have attached a slightly modified version of the slide 7. The modification is the replacement of the 802.3 interface between carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent section monitoring capabilities and it is now not necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level between these P and left S-PE nodes. This is reflected by the absence of the lower blue Section MEP functions. [maarten] On the side of the adaptation functions between MPLS-TP Section layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry header" (in analogy to the priority vlan tag in ethernet). The use of such "P-LSE" header on the MPLS-TP over SDH interface would be required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets passed through the carrier B network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM packets have the same priority/drop eligibility, then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/drop eligible level to the the unlabelled (section OAM) packets. [maarten] For the latter case, the MPLS-TP Section layer signal will have its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP Section layer signal will have its section OAM equipped with 'P-LSP' label as BOS and GAL as second label. [maarten] Assume the latter case, then the blue MIP function in the left S-PE node will process the GAL as BOS. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering. [maarten] I understand why we were coming to different conclusions. I hope I have clarified my view with the SDH physical media layer example. [maarten] You may now also understand why the definition of Section layer in G.805 defines that the section layer network is concerned with all functions which"**provide for the transfer of infomation between locations in path layer networks**. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the section layer connection. [maarten] But in all honesty, most of the Section layer connections are terminating at the same ports as their underlying physical media layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that section layer connections terminate at adjacent nodes. Someone who looks beyond its own network will conclude that section layer connections terminate in nodes that provide access to path layer signals. That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only. [maarten] It is my understanding that we are missing a description which explicitly describes the mapping of labels onto layers. One MPLS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation results is too large to attach, I will email you a copy privately. I have attached a summary of the results up to this point in time. Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion. [maarten] I have understood that that decision has been made. Refer to the SB10 comment "Yes. S=1 does not indicate the boundary between the client and server. It indicates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1. Maarten, I greatly appreciate your input and our discussion. [maarten] I appreciate your questions and discussion. Regards, Maarten Regards, Greg On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers wrote: Hi Greg, The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances, of which the top MTP layer is shared by carrier A and B. See slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer networks. In the attached ethernet-connection-concepts file you find the same case illustrated also on slide 7. Other slides illustrate other cases of carrier-carrier and customer-carrier interactions. Note that the functional models for the MPLS-TP and Ethernet cases are the same; I already had the Ethernet models and have converted those into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is the encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) header. Regards, Maarten _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 17:55 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, so this is carrier's carrier scenario when MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP section by intermediate nodes of server MPLS-TP layer be just plain violation of server-client model? Regards, Greg On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers wrote: Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_NjKuAVBGGq3TqSZvtKUSKQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Sasha,

> In short, LERs do not look at the next label if they do not terminate the previous one.

> Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane.

If what you state is correct there is a serious problem within the existing draft specification for MPLS-TP. These functional models describe a part of the required functional behaviour in a (packet) transport network of any technology.

I doubt that such problem exist... so the MEPs and MIPs in my models are all addressable (and hence usable) in MPLS-TP...

Let's analyse the left inter domain interface between carrier A's P node and B's left S-PE node as an exercise...

1) there is a MPLS-TP Section layer transport path (VSC) between carrier A nodes P-left and P-right

2) there is a MPLS-TP Section layer transport path segment (VSC Segment) between nodes P-left and S-PE-left

3) there is a MPLS-TP transport service layer transport path (VCC) between nodes S-PE-left and S-PE-right (yellow MEPs).

- The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL.

- The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL.

- The lower blue MEP in node S-PE-left has to process all packets with top of stack the GAL.

- The blue MIP in node S-PE-left has to process all packets generated by the higher blue MEP in node P of which the TTL expires; these packets arrive at node S-PE-left with two labels, of which the bottom of stack label is the GAL and the top of stack label is a regular LSP label.

- The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets; the new label value will be the value inserted by the left yellow MEP in the S-PE-left node (indicated by LSE next to the yellow MEP symbol).

- If the packet was a VSC OAM packet of which the TTL expires, the packet will be extracted by the blue MIP within the VSC.

- The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in the S-PE-left node (i.e. egress MIP issue applies).

- The VCC signal is multiplexed into an MPLS-TP transport path layer transport path (VPC) and its packets are prepended with a new LSP label identifying the VCC.

- Etc.

- In the reverse direction, the VPC terminates on the right NNI port of the S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All other VCC LSP related packets are forwarded to the egress port which is connected to carrier A's P node.

- The VCC LSP terminates on the egress port, and the LSP label identifying this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can now determine which packets carry the VCC LSP OAM by checking for the GAL as next top label.

- The VCC LSP label is also removed from the non-VCC LSP OAM packets and it is possible that on one of those packets the TTL expires. Such packets are processed by the blue MIP function above the yellow MEP function in the S-PE-left node.

- The outer label on packets of which the TTL has not expired will be swapped, and LSP OAM will be added in the lower blue section layer MEP on the S-PE-left node. This OAM will be output with GAL as top and bottom of stack label.

- Etc.

I can't find a problem in the above required behaviour, besides the well known egress-MIP identification problem.

There is always an outer LSP label being terminated when a MEP function is following and LSP OAM has to be extracted and processed.

In some cases the LSP terminates on an ingress port (DOWN MEP), in other cases the LSP terminates on an egress port (UP MEP).

See inline for more comment...

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: zaterdag 23 januari 2010 8:57
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org; 'Greg Mirsky'
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,

I may be missing something important, but how iy seems that you ignore the fundamental differences between Ethernet and MPLS data planes in your analysis.

[maarten] I am absolutely not ignoring the differences between Ethernet and MPLS data planes, as I am also not ignoring the commonalities.

[maarten] What I mean is that it is possible to set up an e.g. 9-port mp2mp LSP connection in the MPLS technology and order an mpls switch to read the inner (PW) label and use the value of this inner label to forward the packet to one of the 9 output ports of the mp2mp LSP... It should be clear that a switch with such capability has a feature which is not described in the MPLS RFCs; i.e. it is a proprietary extension which I am describing below to illustrate that such extension does not interfere with the standardized MPLS behaviour, and that it does not change that behaviour.

-----------------

[maarten] It is very simple to test the forwarding of packets in such mp2mp LSP in a research lab :-)...; inner label values 1000-1999 were delivered at output port 1, inner label values 2000-2999 were delivered at output 2, inner label values 3000-3999 were delivered at output port 3, etc. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and forwards all packets with inner label value 1xxx to output port 1, with inner label value 2xxx to output port 2, etc.

[maarten] Another nice test application for such LSP is in a physical ring; e.g. with 8 nodes. In this case you can identify the destination ring node in the 3 most significant bits of the PW label and the output trib card on a ring node by the next 7 bits and the individual PW instances by the 10 least significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via its east line port and packets with inner label values 100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks between nodes 5 and 6, then ring node 0 will change the forwarding of packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port. Node 0 is informed about the break between nodes 6 and 7 by means of a ring-APS message including the number of the node and the interface (east/west) detecting the fault. Ring node 0 will always extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent that packets get looped in the mp2mp Ring-LSP and forward packets with other label values on the east line port to the west line port (and vice versa).

[maarten] to support the transport of p2mp PWs through such mp2mp LSP another set of PW label values was allocated, e.g. 10000-10999. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and in case of a value in the 10xxx range looks up in a table the subset of output ports to which this packet has to be sent.

[maarten] The same mpls switch also supports p2p LSPs and when the outer label value is associated with such p2p LSP it will ignore the inner label value and forward the packet to the output port.

[maarten] The same mpls switch also supports p2mp LSPs and when the out label value is associated with such p2mp LSP the switch will ignore the inner label value and looks up in a table the set of output ports of this p2mp LSP and forwards the packet to all output ports.

[maarten] The same mpls switch also looks at the inner label on the interface port to identify if the packet is an OAM packet and then look at the ACH channel type to identify the type of OAM packet to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; new mpls switch ports will be able to look at inner labels of all packets; this is a similar evolution as we got in ethernet... existing ethernet switches could only look at the TYPE and DA fields to identify if an OAM frame had to be processed (those switches could only support a subset of the Y.1731 OAM), new ethernet switches are looking at the TYPE and MEL fields and can support the full set of Y.1731 OAM.

[maarten] I hope you understand now that it is possible to extend the MPLS data plane specified in the RFCs with a 'connectionless-LSP' capability. Such extended mpls dataplane will then contain a mix of connection oriented-LSPs and connectionless-LSPs. The behaviour of the connection-oriented-LSPs complies with the specifications in the RFCs. The connectionless-LSPs are a bonus.

---------------------

[maarten] An ethernet switch reads the outer vlan identifier and when the outer vlan identifier is associated with a

- p2p VLAN it will ignore the DA value and forward the frame to the output port

- p2mp VLAN it will ignore the DA value and looks up in a table the set of output ports of this p2mp VLAN and forwards the frame to all those output ports

- mp2mp or rmp VLAN it will read the DA and looks up in a table the output port or ports of this mp2mp VLAN to which this frame should be forwarded.

The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases on the interface port to identify if the frame is an OAM frame and then look at the MEL field and OpCode fields to identify the type of OAM frame and its MEG level to see if the packet must be processed in the interface port (and not forwarded to the switch fabric).

[maarten] I don't see as such any functional difference between the mpls and ethernet data planes; the same information elements are present in both data planes, but with a different encoding of this information in the frame/packet... the main difference is that standard mpls switches don't use the inner label value to control forwarding of a packet to a subset of output ports of an LSP, while ethernet switches typically support both the use of the DA value to control forwarding and the don't use of the DA value to control forwarding to a subset of VLAN output ports... but note that there is also a set of ethernet switches that only support don't use of the DA value to control forwarding, i.e. which support only p2p and p2mp VLANs.

Ethernet data plane inherently recognizes "well-know multicast MAC destination addresses". If a switch wants so, it can catch all the frames with such a DA and decide how it treats them "out-of-band".

[maarten] The well-known MAC multicast destination addresses listed in Table 8-1/802.1Q are identifying management plane and control plane protocols that are carried over the links; those frames are not belonging to the user traffic carried in the VLANs. In MPLS-TP similar management and control plane information is carried via the MCC and SCC packets specified in RFC5718.

[maarten] If you read G.8021 then you will notice that the well-know multicast MAC destination addresses for OAM are not being recognized in the ETH atomic functions processing Ethernet OAM.

Note that G.8021 has never used the DA field in the Ethernet OAM frame as a means to identify OAM from non-OAM frames, as Y.1731 has from day one specified OAM frames that carry a unicast address which do not contain these well-known OAM multicase destination addresses.

Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the MEL field to identify the MEG level and the OpCode field to identify the type of OAM.

[maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from non-LSP OAM packets, the label stack to identify the MEG level and the ACH channel type field to identify the type of OAM.

I.e. the same information, just a different encoding.

All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is exactly what allows separation between addressing and MEP/MIP levels in 802.1ag.

[maarten] As indicated above, your understanding of Ethernet OAM protocol processing does not align with Y.1731/G.8021 specifications.

[maarten] The unicast LBM OAM is a special OAM frame/packet as it requires one additional information element; i.e. a MIP identifier. This MIP identifier must be carried in the LBM OAM frame/packet in both Ethernet and in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in a bidirectional p2mp LSP located at the same hop count from the MEP. Because the bidir p2mp LSP was only recently described in this mailinglist the implications of such LSP on the loopback OAM have not yet been investigated and documented.

[maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP identifier field when the OAM frame/packet is identified as a LBM OAM. The MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the OAM framework. But if there is a real demand for such bidir p2mp LSP or PW, we should include the MIP Identifier in the OAM framework document for loopback OAM.

The disadvantage of this approach is that Ethernet OAM frames are not necessarily fate-sharing with the data traffic.

[maarten] All Ethernet OAM frames fate share with the VLAN (i.e. the Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets will fate share with the PW and LSP (i.e. the MPLS transport entities).

[maarten] There is one type of OAM that has to fate share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both the VLAN/PW/LSP and the frames/packets for which the ingress count is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs there is a problem to meet the second requirement. I.e. no difference as such between Ethernet and MPLS.

The MPLS data plane is defined in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet well-know multicast MAC destination addresses is the reserved Router Alert Label. But its usage has been rejected for usage in MPLS-TP OAM exactly because fate-sharing of data and OAM packets could be broken. Instead, MPLS-TP uses two different mechanisms:

GAL. This mechanism can only be used to address MEPs, because the LER processing a packet with the GAL at some level in the label stack is not allowed to look at it unless it terminates all the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to the loopback interface"). [maarten] The ethernet equivalent to the GAL is the OAM ethertype value 89-02.
TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in the first label stack entry following all the labels terminated by the supporting node. [maarten] As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it will have to include the MIP Identifier to address the MIP that has to perform the loopback.

[maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry management plane frames. This is similar to the MPLS-TP MCC OAM packet defined in RFC5718.

Regards,

Maarten

In short, LERs do not look at the next label if they do not terminate the previous one.

Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane.

My 2c,

Sasha

From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers [maarten.vissers@huawei.com]
Sent: Saturday, January 23, 2010 7:37 AM
To: 'Greg Mirsky'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Hi Greg,

See inline..

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: vrijdag 22 januari 2010 20:29
To: Maarten Vissers
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,
I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section.

In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A.

[maarten] Correct.

S-PEs of Carrier B are unaware of that MPLS Section.

[maarten] not correct. The figure shows two MPLS-TP Section layer MEG levels; the top level MEG has its endpoints (blue MEP functions) in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and in right S-PE and P' nodes.

[maarten] The most left and right S-PEs of carrier B terminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP Section layer OAM from the top MEG level.

[maarten] I have attached a slightly modified version of the slide 7. The modification is the replacement of the 802.3 interface between carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent section monitoring capabilities and it is now not necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level between these P and left S-PE nodes. This is reflected by the absence of the lower blue Section MEP functions.

[maarten] On the side of the adaptation functions between MPLS-TP Section layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry header" (in analogy to the priority vlan tag in ethernet). The use of such "P-LSE" header on the MPLS-TP over SDH interface would be required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets passed through the carrier B network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM packets have the same priority/drop eligibility, then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/drop eligible level to the the unlabelled (section OAM) packets.

[maarten] For the latter case, the MPLS-TP Section layer signal will have its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP Section layer signal will have its section OAM equipped with 'P-LSP' label as BOS and GAL as second label.

[maarten] Assume the latter case, then the blue MIP function in the left S-PE node will process the GAL as BOS.

Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering.

[maarten] I understand why we were coming to different conclusions. I hope I have clarified my view with the SDH physical media layer example.

[maarten] You may now also understand why the definition of Section layer in G.805 defines that the section layer network is concerned with all functions which"**provide for the transfer of infomation between locations in path layer networks**.

It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the section layer connection.

[maarten] But in all honesty, most of the Section layer connections are terminating at the same ports as their underlying physical media layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that section layer connections terminate at adjacent nodes. Someone who looks beyond its own network will conclude that section layer connections terminate in nodes that provide access to path layer signals.

That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only.

[maarten] It is my understanding that we are missing a description which explicitly describes the mapping of labels onto layers. One MPLS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation results is too large to attach, I will email you a copy privately. I have attached a summary of the results up to this point in time.

Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion.

[maarten] I have understood that that decision has been made. Refer to the SB10 comment "Yes. S=1 does not indicate the boundary between the client and server. It indicates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1.

Maarten, I greatly appreciate your input and our discussion.

[maarten] I appreciate your questions and discussion.

Regards,

Maarten

Regards,
Greg

On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers <maarten.vissers@huawei.com> wrote:

Hi Greg,

The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances, of which the top MTP layer is shared by carrier A and B. See slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer networks. In the attached ethernet-connection-concepts file you find the same case illustrated also on slide 7.

Other slides illustrate other cases of carrier-carrier and customer-carrier interactions.

Note that the functional models for the MPLS-TP and Ethernet cases are the same; I already had the Ethernet models and have converted those into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is the encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) header.

Regards,

Maarten

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: vrijdag 22 januari 2010 17:55
To: Maarten Vissers

Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Maarten,
so this is carrier's carrier scenario when MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP section by intermediate nodes of server MPLS-TP layer be just plain violation of server-client model?

Regards,
Greg

On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers <maarten.vissers@huawei.com> wrote:

Greg,

It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes.

Regards,

Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky
Sent: donderdag 21 januari 2010 22:21
To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Dear Editors and All,
I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer.
Your clarification is greatly appreciated.

Regards,
Greg

--Boundary_(ID_NjKuAVBGGq3TqSZvtKUSKQ)-- From maarten.vissers@huawei.com Sat Jan 23 21:10:52 2010 Return-Path: X-Original-To: mpls-tp@core3.amsl.com Delivered-To: mpls-tp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28E03A6784; Sat, 23 Jan 2010 21:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTXOgIKeTwq9; Sat, 23 Jan 2010 21:10:46 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id B215C3A6782; Sat, 23 Jan 2010 21:10:45 -0800 (PST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWQ00B09JPWNW@szxga02-in.huawei.com>; Sun, 24 Jan 2010 13:10:44 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KWQ00E7QJPVO1@szxga02-in.huawei.com>; Sun, 24 Jan 2010 13:10:43 +0800 (CST) Received: from M00900002 ([116.6.21.230]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KWQ00JJAJPVIN@szxml01-in.huawei.com>; Sun, 24 Jan 2010 13:10:43 +0800 (CST) Date: Sun, 24 Jan 2010 06:10:41 +0100 From: Maarten Vissers In-reply-to: <000001ca9c45$7c86dc90$e6150674@china.huawei.com> To: 'Alexander Vainshtein' Message-id: <000501ca9cb3$93aba860$e6150674@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_rUh3LCL9FAIEMbCycvshOg)" Thread-index: AcqbmSNrZOC6OkVyTYie1ES9/D/jNAARX32gAAgKxJoABxrLQAAjGCMg Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: [mpls-tp] additional LSP forwarding capabilities [was: RE: RFC 5586: Intermediate nodes on MPLS Section] X-BeenThere: mpls-tp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MPLS-TP Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 05:10:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rUh3LCL9FAIEMbCycvshOg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sasha, I have described in my previous email to you how the mpls data plane could be extended to support mp2mp LSPs (e.g. Ring-LSPs) and that such additional capability is backwards compatible with the current standardized behaviour. I did this to illustrate the differences and commonalities between mpls and ethernet data planes. I would like to extend this illustration of commonalities and differences of those two data plane by illustrating an extension of the unidir p2mp LSP functionality and how one can emulate PBT with LSPs. Neither of those extensions will impact the compatibility with existing implementations; i.e. those extensions would be pure additions. 1) if one would set up a unidir p2mp LSP with 1 input port and 9 output ports and want to transport over this p2mp LSP a large number of p2p PWs, then this is possible today (but is not efficient)... allocate the PW label values such that PWs destined for output port 1 have PW label values 1000-1999, PWs destined for output port 2 have PW label values 2000-2999, etc. In a traditional p2mp LSP, all PWs are delivered to all 9 output ports, and output port 1 will then discard packets that have PW label values 2000 and higher. Output port 2 will discard packets with PW label values 16-1999 and 3000 and higher, etc. If the intermediate P nodes would be able to read the inner (PW) label as described in my earlier email, then such P node can for this specific p2mp LSP limit the forwarding of the packets to one output port; i.e. the undir p2mp LSP is becoming a unidir rooted-mp LSP. The ability to read the inner label within a selected LSP and use its value in the forwarding decision of the packet does not impact the forwarding in the other LSPs. >From a connection management perspective (management or control plane) the set up of the basic p2mp connection is the same, there is only an additional configuration necessary of the forwarding process in each P node; i.e. configure PW label range to output port mapping. E.g. an intermediate P node supporting this p2mp LSP may have 1 input port and 3 output ports (ports A, B, C) for this p2mp LSP; packets with inner label values 1xxx, 2xxx, 3xxx have to be forwarded to output port A, packets with inner label values 4xxx, 5xxx, 6xxx have to be forwarded to output port B and packets with inner label values 7xxx, 8xxx, 9xxx have to be forwarded to output port C. If one would set up both a p2mp LSP and a co-routed mp2p LSP then we would get a bidir rooted-mp LSP, which has similar forwarding behaviour as the rooted-mp VLAN. 2) PBT provides a full mesh of p2p ESPs between Ethernet/PBT PE nodes. The PBT P nodes forward on the basis of a mp2p construct. In the mpls data plane the same behaviour can be obtained by setting up a full mesh of p2p LSPs between S-PE nodes and transport those p2p LSPs over a full mesh of mp2p LSPs. The NNI port on the S-PE node will then push a p2p LSP label (PP label) and a mp2p LSP label (MPP label). As pushing/popping multiple labels in an NNI port seems a trivial item these days (i.e. this capability is deployed to implement tandem connection/segment monitoring in MPLS-TP), it should be simple to apply it the run p2p LSPs over mp2p LSP. The P nodes forward on the basis of the MPP label. The S-PE nodes terminate both MPP label and PP label and forward the PWs, packet PWs, serviceLSPs and segment monitor LSPs which were transported via the PP LSPs. If desired it is possible to structure the PP LSP label values, and have the most significant bits of this PP label identify the source S-PE NNI port; but I don't think that mpls data plane has this as a requirement; i.e. it can handle unstructured sets of PP label values. Note that http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03 LSP OAM supports the OAM needed in such mp2p LSP transport paths. If one would set up two diversely routed sets of mp2p LSPs it is possible to emulate the PBT protection swithcing. PW, packet PW, service LSP, segment monitoring PW/LSP packets are under normal conditions transported via the Working PP LSP over the Working MPP LSP. If this one fails, then the S-PE will send the packets over the Protection PP LSP over the Protection MPP LSP. Note that the p2p LSPs can be monitored for connectivity and performance (e.g. packet loss). The mp2p LSPs can only be monitored for connectivity; packet loss can not be monitored if unstructured PP labels are used. As the mp2p LSP is only used to reduce the number of entries in the P node switching table it is not a problem that packet loss in the mp2p LSP can not be monitored. I hope I was able to illustrate that there is not much difference between the ethernet and mpls data planes, and that with minimal extensions in the forwarding control of packets within an LSP it is possible to expand the mpls data plane capabilities that today are only provided in the ethernet data plane, without a need to change the existing mpls packet formats and without impacting the existing standardized behaviour. Please note that I am not proposing to introduce such extensions into the mpls data plane. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers Sent: zaterdag 23 januari 2010 17:03 To: 'Alexander Vainshtein' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Sasha, > In short, LERs do not look at the next label if they do not terminate the previous one. > Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane. If what you state is correct there is a serious problem within the existing draft specification for MPLS-TP. These functional models describe a part of the required functional behaviour in a (packet) transport network of any technology. I doubt that such problem exist... so the MEPs and MIPs in my models are all addressable (and hence usable) in MPLS-TP... Let's analyse the left inter domain interface between carrier A's P node and B's left S-PE node as an exercise... 1) there is a MPLS-TP Section layer transport path (VSC) between carrier A nodes P-left and P-right 2) there is a MPLS-TP Section layer transport path segment (VSC Segment) between nodes P-left and S-PE-left 3) there is a MPLS-TP transport service layer transport path (VCC) between nodes S-PE-left and S-PE-right (yellow MEPs). - The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL. - The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL. - The lower blue MEP in node S-PE-left has to process all packets with top of stack the GAL. - The blue MIP in node S-PE-left has to process all packets generated by the higher blue MEP in node P of which the TTL expires; these packets arrive at node S-PE-left with two labels, of which the bottom of stack label is the GAL and the top of stack label is a regular LSP label. - The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets; the new label value will be the value inserted by the left yellow MEP in the S-PE-left node (indicated by LSE next to the yellow MEP symbol). - If the packet was a VSC OAM packet of which the TTL expires, the packet will be extracted by the blue MIP within the VSC. - The yellow MEP inserts the LSP OAM into the carrier A's VSC, creating a monitored VSC Segment, and treats this VSC Segment as one of its VCCs. This VCC related LSP OAM will pass through a VCC MIP on the egress NNI port in the S-PE-left node (i.e. egress MIP issue applies). - The VCC signal is multiplexed into an MPLS-TP transport path layer transport path (VPC) and its packets are prepended with a new LSP label identifying the VCC. - Etc. - In the reverse direction, the VPC terminates on the right NNI port of the S-PE-left node, providing access the VCC LSPs carried in the VPC. If the TTL of a VCC LSP OAM expires the VCC LSP MIP function will process the OAM. All other VCC LSP related packets are forwarded to the egress port which is connected to carrier A's P node. - The VCC LSP terminates on the egress port, and the LSP label identifying this VCC LSP is terminated; the yellow VCC LSP MEP on the egress port can now determine which packets carry the VCC LSP OAM by checking for the GAL as next top label. - The VCC LSP label is also removed from the non-VCC LSP OAM packets and it is possible that on one of those packets the TTL expires. Such packets are processed by the blue MIP function above the yellow MEP function in the S-PE-left node. - The outer label on packets of which the TTL has not expired will be swapped, and LSP OAM will be added in the lower blue section layer MEP on the S-PE-left node. This OAM will be output with GAL as top and bottom of stack label. - Etc. I can't find a problem in the above required behaviour, besides the well known egress-MIP identification problem. There is always an outer LSP label being terminated when a MEP function is following and LSP OAM has to be extracted and processed. In some cases the LSP terminates on an ingress port (DOWN MEP), in other cases the LSP terminates on an egress port (UP MEP). See inline for more comment... _____ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: zaterdag 23 januari 2010 8:57 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org; 'Greg Mirsky' Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Maarten, I may be missing something important, but how iy seems that you ignore the fundamental differences between Ethernet and MPLS data planes in your analysis. [maarten] I am absolutely not ignoring the differences between Ethernet and MPLS data planes, as I am also not ignoring the commonalities. [maarten] What I mean is that it is possible to set up an e.g. 9-port mp2mp LSP connection in the MPLS technology and order an mpls switch to read the inner (PW) label and use the value of this inner label to forward the packet to one of the 9 output ports of the mp2mp LSP... It should be clear that a switch with such capability has a feature which is not described in the MPLS RFCs; i.e. it is a proprietary extension which I am describing below to illustrate that such extension does not interfere with the standardized MPLS behaviour, and that it does not change that behaviour. ----------------- [maarten] It is very simple to test the forwarding of packets in such mp2mp LSP in a research lab :-)...; inner label values 1000-1999 were delivered at output port 1, inner label values 2000-2999 were delivered at output 2, inner label values 3000-3999 were delivered at output port 3, etc. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and forwards all packets with inner label value 1xxx to output port 1, with inner label value 2xxx to output port 2, etc. [maarten] Another nice test application for such LSP is in a physical ring; e.g. with 8 nodes. In this case you can identify the destination ring node in the 3 most significant bits of the PW label and the output trib card on a ring node by the next 7 bits and the individual PW instances by the 10 least significant bits. Number the ring nodes from 0 to 7. Now ring node 0 will forward the packets with inner label values 001/010/011xxxxxxxxxxxxxxxxx via its east line port and packets with inner label values 100/101/110/111xxxxxxxxxxxxxxxxx via its west line port. If the ring breaks between nodes 5 and 6, then ring node 0 will change the forwarding of packets with inner label values 100/101xxxxxxxxxxxxxxxxx from the west line port to the east line port. Node 0 is informed about the break between nodes 6 and 7 by means of a ring-APS message including the number of the node and the interface (east/west) detecting the fault. Ring node 0 will always extract packets with inner label values 000xxxxxxxxxxxxxxxxxxx to prevent that packets get looped in the mp2mp Ring-LSP and forward packets with other label values on the east line port to the west line port (and vice versa). [maarten] to support the transport of p2mp PWs through such mp2mp LSP another set of PW label values was allocated, e.g. 10000-10999. The mpls switch reads the outer label value to identify the LSP, then reads the inner label value and in case of a value in the 10xxx range looks up in a table the subset of output ports to which this packet has to be sent. [maarten] The same mpls switch also supports p2p LSPs and when the outer label value is associated with such p2p LSP it will ignore the inner label value and forward the packet to the output port. [maarten] The same mpls switch also supports p2mp LSPs and when the out label value is associated with such p2mp LSP the switch will ignore the inner label value and looks up in a table the set of output ports of this p2mp LSP and forwards the packet to all output ports. [maarten] The same mpls switch also looks at the inner label on the interface port to identify if the packet is an OAM packet and then look at the ACH channel type to identify the type of OAM packet to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). The existing mpls switch ports will only be able to look at inner labels of packets of which the outer label is terminated; new mpls switch ports will be able to look at inner labels of all packets; this is a similar evolution as we got in ethernet... existing ethernet switches could only look at the TYPE and DA fields to identify if an OAM frame had to be processed (those switches could only support a subset of the Y.1731 OAM), new ethernet switches are looking at the TYPE and MEL fields and can support the full set of Y.1731 OAM. [maarten] I hope you understand now that it is possible to extend the MPLS data plane specified in the RFCs with a 'connectionless-LSP' capability. Such extended mpls dataplane will then contain a mix of connection oriented-LSPs and connectionless-LSPs. The behaviour of the connection-oriented-LSPs complies with the specifications in the RFCs. The connectionless-LSPs are a bonus. --------------------- [maarten] An ethernet switch reads the outer vlan identifier and when the outer vlan identifier is associated with a - p2p VLAN it will ignore the DA value and forward the frame to the output port - p2mp VLAN it will ignore the DA value and looks up in a table the set of output ports of this p2mp VLAN and forwards the frame to all those output ports - mp2mp or rmp VLAN it will read the DA and looks up in a table the output port or ports of this mp2mp VLAN to which this frame should be forwarded. The ethernet switch also looks at the inner TYPE (i.e. TPID) in all cases on the interface port to identify if the frame is an OAM frame and then look at the MEL field and OpCode fields to identify the type of OAM frame and its MEG level to see if the packet must be processed in the interface port (and not forwarded to the switch fabric). [maarten] I don't see as such any functional difference between the mpls and ethernet data planes; the same information elements are present in both data planes, but with a different encoding of this information in the frame/packet... the main difference is that standard mpls switches don't use the inner label value to control forwarding of a packet to a subset of output ports of an LSP, while ethernet switches typically support both the use of the DA value to control forwarding and the don't use of the DA value to control forwarding to a subset of VLAN output ports... but note that there is also a set of ethernet switches that only support don't use of the DA value to control forwarding, i.e. which support only p2p and p2mp VLANs. Ethernet data plane inherently recognizes "well-know multicast MAC destination addresses". If a switch wants so, it can catch all the frames with such a DA and decide how it treats them "out-of-band". [maarten] The well-known MAC multicast destination addresses listed in Table 8-1/802.1Q are identifying management plane and control plane protocols that are carried over the links; those frames are not belonging to the user traffic carried in the VLANs. In MPLS-TP similar management and control plane information is carried via the MCC and SCC packets specified in RFC5718. [maarten] If you read G.8021 then you will notice that the well-know multicast MAC destination addresses for OAM are not being recognized in the ETH atomic functions processing Ethernet OAM. Note that G.8021 has never used the DA field in the Ethernet OAM frame as a means to identify OAM from non-OAM frames, as Y.1731 has from day one specified OAM frames that carry a unicast address which do not contain these well-known OAM multicase destination addresses. Y.1731/G.8021 use the TYPE field to separate OAM from non-OAM frames, the MEL field to identify the MEG level and the OpCode field to identify the type of OAM. [maarten] MPLS-TP will use the LABEL field to separate LSP-OAM from non-LSP OAM packets, the label stack to identify the MEG level and the ACH channel type field to identify the type of OAM. I.e. the same information, just a different encoding. All Ethernet protocols operate in this way, 802.1ag is not an exception. And this is exactly what allows separation between addressing and MEP/MIP levels in 802.1ag. [maarten] As indicated above, your understanding of Ethernet OAM protocol processing does not align with Y.1731/G.8021 specifications. [maarten] The unicast LBM OAM is a special OAM frame/packet as it requires one additional information element; i.e. a MIP identifier. This MIP identifier must be carried in the LBM OAM frame/packet in both Ethernet and in bidirectional p2mp MPLS-TP LSP cases; in MPLS-TP to differentiate MIPs in a bidirectional p2mp LSP located at the same hop count from the MEP. Because the bidir p2mp LSP was only recently described in this mailinglist the implications of such LSP on the loopback OAM have not yet been investigated and documented. [maarten] Both in Ethernet and MPLS OAM the OAM process must read this MIP identifier field when the OAM frame/packet is identified as a LBM OAM. The MIP identifier in Ethernet OAM is the EUI-48 of the physical subsystem on which the MIP resides, while in MPLS-TP OAM this is not yet in scope of the OAM framework. But if there is a real demand for such bidir p2mp LSP or PW, we should include the MIP Identifier in the OAM framework document for loopback OAM. The disadvantage of this approach is that Ethernet OAM frames are not necessarily fate-sharing with the data traffic. [maarten] All Ethernet OAM frames fate share with the VLAN (i.e. the Ethernet transport entity) in a similar manner as all MPLS-TP OAM packets will fate share with the PW and LSP (i.e. the MPLS transport entities). [maarten] There is one type of OAM that has to fate share with more then the VLAN/PW/LSP; i.e. the frame/packet loss OAM has to fate share with both the VLAN/PW/LSP and the frames/packets for which the ingress count is transported in this OAM frame/packet. In p2p/p2mp VLANs/PWs/LSPs there is no problem to meet this requirement. In rmp/mp2mp VLANs and mp2p PWs/LSPs there is a problem to meet the second requirement. I.e. no difference as such between Ethernet and MPLS. The MPLS data plane is defined in RFC 3031, 30302 and (for upstream-allocated labels) in RFC 5331, 5332. Its analog of Ethernet well-know multicast MAC destination addresses is the reserved Router Alert Label. But its usage has been rejected for usage in MPLS-TP OAM exactly because fate-sharing of data and OAM packets could be broken. Instead, MPLS-TP uses two different mechanisms: 1. GAL. This mechanism can only be used to address MEPs, because the LER processing a packet with the GAL at some level in the label stack is not allowed to look at it unless it terminates all the labels above it are terminated (i.e., its ILM entries for these labels must be "pop and forward to the loopback interface"). [maarten] The ethernet equivalent to the GAL is the OAM ethertype value 89-02. 2. TTL expiration. This is the only mechanism for addressing MIPs in MPLS-TP. And, of course, TTL expiration must occur in the first label stack entry following all the labels terminated by the supporting node. [maarten] As described above, as soon as MPLS-TP has to support bidir p2mp LSPs/PWs it will have to include the MIP Identifier to address the MIP that has to perform the loopback. [maarten] Ethernet OAM Y.1731 specifies an Ethernet MCC OAM frame to carry management plane frames. This is similar to the MPLS-TP MCC OAM packet defined in RFC5718. Regards, Maarten In short, LERs do not look at the next label if they do not terminate the previous one. Hence I think that some of the MEPs you've defined are non-addressable (and hence unusable) in MPLS-TP which shares the MPLS data plane. My 2c, Sasha _____ From: mpls-tp-bounces@ietf.org [mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers [maarten.vissers@huawei.com] Sent: Saturday, January 23, 2010 7:37 AM To: 'Greg Mirsky' Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Hi Greg, See inline.. _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 20:29 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, I'll concentrate, as you suggested, on the slide #7 and the following you've wrote "The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances". I think that from the definition of MPLS Section follows that there can not be an intermediate MPLS node on a given MPLS Section which is aware of that Section. In your example (slide #7) nodes P and P' (to differentiate them from left to right) of Carrier A are terminating points of MPLS Section of Carrier A. [maarten] Correct. S-PEs of Carrier B are unaware of that MPLS Section. [maarten] not correct. The figure shows two MPLS-TP Section layer MEG levels; the top level MEG has its endpoints (blue MEP functions) in the carrier A P and P' nodes, the bottom level MEG has its end points in the interface ports of P and left S-PE and in right S-PE and P' nodes. [maarten] The most left and right S-PEs of carrier B terminate the physical media layer (the 802.3 ETY layer) and then the MPLS-TP Section TCM/Segment OAM in the blue colored MEP function. On top of this MEP function there is a (blue) MPLS-TP Section layer MIP function, which will process the MPLS-TP Section layer OAM from the top MEG level. [maarten] I have attached a slightly modified version of the slide 7. The modification is the replacement of the 802.3 interface between carrier A's P node and the left S-PE node of carrier B by an SDH STM-N interface. Such SDH interface has excellent section monitoring capabilities and it is now not necessary to instantiate the MPLS-TP Section layer TCM/Segment MEG level between these P and left S-PE nodes. This is reflected by the absence of the lower blue Section MEP functions. [maarten] On the side of the adaptation functions between MPLS-TP Section layer and SDH layers (blue/grey colored trapezoid symbols) I have indicated "P-LSE" to represent that it may be necessary to insert a kind of "priority label stack entry header" (in analogy to the priority vlan tag in ethernet). The use of such "P-LSE" header on the MPLS-TP over SDH interface would be required when carrier A wants to have explicit control over the priority and drop eligibility of each of the MPLS-TP packets passed through the carrier B network; i.e. including the MPLS-TP Section OAM packets. If all Section OAM packets have the same priority/drop eligibility, then insertion of such P-LSE header is not necessary as carrier B's S-PE node can assign the right priority/drop eligible level to the the unlabelled (section OAM) packets. [maarten] For the latter case, the MPLS-TP Section layer signal will have its section OAM equipped with GAL as BOS. For the former case, the MPLS-TP Section layer signal will have its section OAM equipped with 'P-LSP' label as BOS and GAL as second label. [maarten] Assume the latter case, then the blue MIP function in the left S-PE node will process the GAL as BOS. Thus, when Node P sends OAM with GAL as BOS to monitor the P-P' Section, none of nodes of Carrier B, including S-PEs, should bother to process the GAL. Doing otherwise will break client-server layering. [maarten] I understand why we were coming to different conclusions. I hope I have clarified my view with the SDH physical media layer example. [maarten] You may now also understand why the definition of Section layer in G.805 defines that the section layer network is concerned with all functions which"**provide for the transfer of infomation between locations in path layer networks**. It is this latter item that allows section layer trails to span multiple physical media layer trails, and thus to have intermediate nodes in the section layer connection. [maarten] But in all honesty, most of the Section layer connections are terminating at the same ports as their underlying physical media layer connections. Someone who looks only at the appearances of section layers inside one network will conclude that section layer connections terminate at adjacent nodes. Someone who looks beyond its own network will conclude that section layer connections terminate in nodes that provide access to path layer signals. That is why I can not agree that an intermediate node contains instances of multiple MPLS-TP networks. I think of a node as performing its functions at certain MPLS-TP network layer only. [maarten] It is my understanding that we are missing a description which explicitly describes the mapping of labels onto layers. One MPLS-TP layer network will in my understanding contain one or more labels. As the ppt file with my investigation results is too large to attach, I will email you a copy privately. I have attached a summary of the results up to this point in time. Another question is whether Carrier B sets its VC label as BOS or not, as I understand we haven't decided yet with number of BOS in carrier's carrier scenario. But that, to me, is separate discussion. [maarten] I have understood that that decision has been made. Refer to the SB10 comment "Yes. S=1 does not indicate the boundary between the client and server. It indicates the boundary between the label stack and the label stack payload." in the draft-ietf-mpls-tp-framework-07-post-review-of ITU-T-informal-cts-19-Jan-2010.doc. This is now inlcuded in draft-ietf-mpls-tp-framework-08, see section 3.4.1. Maarten, I greatly appreciate your input and our discussion. [maarten] I appreciate your questions and discussion. Regards, Maarten Regards, Greg On Fri, Jan 22, 2010 at 10:32 AM, Maarten Vissers wrote: Hi Greg, The intermediate nodes contain multiple MPLS-TP (MTP) layer network instances, of which the top MTP layer is shared by carrier A and B. See slide 7 in the mplstp-connection-concepts file. Note that the same applies for the case of Ethernet (ETH) layer networks. In the attached ethernet-connection-concepts file you find the same case illustrated also on slide 7. Other slides illustrate other cases of carrier-carrier and customer-carrier interactions. Note that the functional models for the MPLS-TP and Ethernet cases are the same; I already had the Ethernet models and have converted those into MPLS-TP equivalent models to illustrate this section layer question. The difference between both technologies is the encoding of MEG levels; in Ethernet via the MEG Level (MEL) field, in MPLS-TP via a Label Stack Entry (LSE) header. Regards, Maarten _____ From: Greg Mirsky [mailto:gregimirsky@gmail.com] Sent: vrijdag 22 januari 2010 17:55 To: Maarten Vissers Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Maarten, so this is carrier's carrier scenario when MPLS-TP section is client of MPLS-TP transport? But wouldn't presumed processing of client MPLS-TP section by intermediate nodes of server MPLS-TP layer be just plain violation of server-client model? Regards, Greg On Fri, Jan 22, 2010 at 7:51 AM, Maarten Vissers wrote: Greg, It is not uncommon to carry a section layer signal as a service through the network of another carrier. E.g. Ethernet port based services carry the Ethernet section layer signals as a service through the transport network. The compatible MPLS type of port based service would carry the MPLS section layer signal as a service through the network of another carrier. The section will now pass through intermediate nodes. Regards, Maarten _____ From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Greg Mirsky Sent: donderdag 21 januari 2010 22:21 To: BOCCI Matthew; martin.vigoureux@alcatel-lucent.com; stbryant@cisco.com Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section Dear Editors and All, I'm puzzled by what looks to me as contradiction between quoted in the RFC 5586 definition of the Section Layer Network and the last paragraph on sub-section 4.2.1.2 MPLS Section. The definition (section 1.3 p.4) refers to section as server layer that provides service between adjacent nodes (my underlining). At the same time, the last paragraph of subsection 4.2.1.2 stipulates behavior of intermediate nodes on an MPLS Section in regard to G-ACh message, the ACH and the GAL. If an MPLS Section is between adjacent nodes, then, as I understand the definition, there can not be intermediate nodes on the section (on the segment, but not on a section) at this particular layer. Your clarification is greatly appreciated. Regards, Greg --Boundary_(ID_rUh3LCL9FAIEMbCycvshOg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Sasha,

I have described in my previous email to you how the mpls data plane could be extended to support mp2mp LSPs (e.g. Ring-LSPs) and that such additional capability is backwards compatible with the current standardized behaviour. I did this to illustrate the differences and commonalities between mpls and ethernet data planes.

I would like to extend this illustration of commonalities and differences of those two data plane by illustrating an extension of the unidir p2mp LSP functionality and how one can emulate PBT with LSPs. Neither of those extensions will impact the compatibility with existing implementations; i.e. those extensions would be pure additions.

1) if one would set up a unidir p2mp LSP with 1 input port and 9 output ports and want to transport over this p2mp LSP a large number of p2p PWs, then this is possible today (but is not efficient)... allocate the PW label values such that PWs destined for output port 1 have PW label values 1000-1999, PWs destined for output port 2 have PW label values 2000-2999, etc.

In a traditional p2mp LSP, all PWs are delivered to all 9 output ports, and output port 1 will then discard packets that have PW label values 2000 and higher. Output port 2 will discard packets with PW label values 16-1999 and 3000 and higher, etc.

If the intermediate P nodes would be able to read the inner (PW) label as described in my earlier email, then such P node can for this specific p2mp LSP limit the forwarding of the packets to one output port; i.e. the undir p2mp LSP is becoming a unidir rooted-mp LSP.

The ability to read the inner label within a selected LSP and use its value in the forwarding decision of the packet does not impact the forwarding in the other LSPs.

From a connection management perspective (management or control plane) the set up of the basic p2mp connection is the same, there is only an additional configuration necessary of the forwarding process in each P node; i.e. configure PW label range to output port mapping.

E.g. an intermediate P node supporting this p2mp LSP may have 1 input port and 3 output ports (ports A, B, C) for this p2mp LSP; packets with inner label values 1xxx, 2xxx, 3xxx have to be forwarded to output port A, packets with inner label values 4xxx, 5xxx, 6xxx have to be forwarded to output port B and packets with inner label values 7xxx, 8xxx, 9xxx have to be forwarded to output port C.

If one would set up both a p2mp LSP and a co-routed mp2p LSP then we would get a bidir rooted-mp LSP, which has similar forwarding behaviour as the rooted-mp VLAN.

2) PBT provides a full mesh of p2p ESPs between Ethernet/PBT PE nodes. The PBT P nodes forward on the basis of a mp2p construct.

In the mpls data plane the same behaviour can be obtained by setting up a full mesh of p2p LSPs between S-PE nodes and transport those p2p LSPs over a full mesh of mp2p LSPs. The NNI port on the S-PE node will then push a p2p LSP label (PP label) and a mp2p LSP label (MPP label).

As pushing/popping multiple labels in an NNI port seems a trivial item these days (i.e. this capability is deployed to implement tandem connection/segment monitoring in MPLS-TP), it should be simple to apply it the run p2p LSPs over mp2p LSP. The P nodes forward on the basis of the MPP label. The S-PE nodes terminate both MPP label and PP label and forward the PWs, packet PWs, serviceLSPs and segment monitor LSPs which were transported via the PP LSPs.

If desired it is possible to structure the PP LSP label values, and have the most significant bits of this PP label identify the source S-PE NNI port; but I don't think that mpls data plane has this as a requirement; i.e. it can handle unstructured sets of PP label values. Note that http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03 LSP OAM supports the OAM needed in such mp2p LSP transport paths.

If one would set up two diversely routed sets of mp2p LSPs it is possible to emulate the PBT protection swithcing. PW, packet PW, service LSP, segment monitoring PW/LSP packets are under normal conditions transported via the Working PP LSP over the Working MPP LSP. If this one fails, then the S-PE will send the packets over the Protection PP LSP over the Protection MPP LSP.

Note that the p2p LSPs can be monitored for connectivity and performance (e.g. packet loss). The mp2p LSPs can only be monitored for connectivity; packet loss can not be monitored if unstructured PP labels are used. As the mp2p LSP is only used to reduce the number of entries in the P node switching table it is not a problem that packet loss in the mp2p LSP can not be monitored.

I hope I was able to illustrate that there is not much difference between the ethernet and mpls data planes, and that with minimal extensions in the forwarding control of packets within an LSP it is possible to expand the mpls data plane capabilities that today are only provided in the ethernet data plane, without a need to change the existing mpls packet formats and without impacting the existing standardized behaviour.

Please note that I am not proposing to introduce such extensions into the mpls data plane.

Regards,

Maarten

From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers
Sent: zaterdag 23 januari 2010 17:03
To: 'Alexander Vainshtein'
Cc: mpls@ietf.org; mpls-tp@ietf.org
Subject: Re: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section