Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10
Lou Berger <lberger@labn.net> Wed, 10 February 2010 14:03 UTC
Return-Path: <lberger@labn.net>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0372728C1EC for <mpls@core3.amsl.com>; Wed, 10 Feb 2010 06:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.215
X-Spam-Level:
X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 1V6H7H8+EdRl for <mpls@core3.amsl.com>; Wed, 10 Feb 2010 06:03:08 -0800 (PST)
Received: from outbound-mail-01.bluehost.com (outbound-mail-01.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id BC68928C1E2 for <mpls@ietf.org>; Wed, 10 Feb 2010 06:03:08 -0800 (PST)
Received: (qmail 14811 invoked by uid 0); 10 Feb 2010 13:57:39 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy4.bluehost.com with SMTP; 10 Feb 2010 13:57:38 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=qtbQrX2U5YwRmQ4c2gTyG/VlepvpdSYDID/NvIeYnIG/Qn2PjsHxxiiNrkCiNpfoklqVopZ4p/IFojW7zrUJ3cT3GFkqFdrGdeMA99osLt9Yk7XJIzsvZsbWgJvABldW;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from <lberger@labn.net>) id 1NfD4T-00008h-No; Wed, 10 Feb 2010 06:57:38 -0700
Message-ID: <4B72BB9C.6060309@labn.net>
Date: Wed, 10 Feb 2010 08:58:52 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20091214 Eudora/3.0b4
MIME-Version: 1.0
To: neil.2.harrison@bt.com
References: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net>
In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C059A471B@E03MVB2-UKBR.domain1.systemhost.net>
X-Enigmail-Version: 0.96a
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: mpls@ietf.org, maarten.vissers@huawei.com, mpls-tp@ietf.org
Subject: Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 14:03:09 -0000
Neil, I have to say I agree 100% with your comments. Particularly that: (a) that there "should" be "an unambiguous way of identifying when one sublayer stack of LSPs ends" -- personally I think the S-bit is perfect for this purpose, and (b) more importantly, that we're limited (as you say, "clinging") to current MPLS practices. It is really (b), the current usage of the MPLS label stack, that has driven me to pragmatically accept that (a) is not achievable in the current MPLS-TP efforts. Lou On 2/9/2010 4:25 PM, neil.2.harrison@bt.com wrote: > Maarten, Please let us not confuse folks with terms like 'transport > entity'....we all know that MPLS-TP will only be using proper > connections because we want to *deterministically and simply* manage > resource. > > However, you are absolutely right to pick-up on the point that an LSP is > *not necessarily* a layer network. AFAIK we now have no way of telling > from looking at the DP whether a suite of nested LSPs is sublayered or > layered...seems one can mix up sublayering and proper client/server > layering of LSPs at will. > > This is not great architectural design practice IMO but this seems to be > happening because we cannot easily satisfy the real transport > requirement whilst clinging on to some old MPLS behaviours. > > Some while ago I suggested (at least to Stewart) that if folks want to > keep sublayering in MPLS-TP, then we should have an unambiguous way of > identifying when one sublayer stack of LSPs ends (say a client layer > MPLS-TP network belonging to party X) and a different sublayer stack of > LSPs begins (say a server layer MPLS-TP network belonging to party Y). > I suggested we should allocate a globally well-known functional label > from the 0-15 set for this important client/server case. We could also > use the same reserved label in MPLS. Note this is consistent with > respecting consistent CI as the label is globally well-known. > > I still think this idea should be given serious consideration due to the > importance (to operators) of being able to have a quite clear > client/server relationship in MPLS-TP between different operating > parties. > > regards, Neil > >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Maarten Vissers >> Sent: 09 February 2010 20:50 >> To: 'Rahul Aggarwal'; 'Loa Andersson' >> Cc: mpls@ietf.org; mpls-tp@ietf.org >> Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >> >> Rahul, >> >> The MPLS-TP LSP is not a layer network. The LSP is a >> transport entity within either the transport service layer >> network, or the transport path layer network, or the section >> layer network. >> >> Regards, >> Maarten >> >> -----Original Message----- >> From: mpls-tp-bounces@ietf.org >> [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Rahul Aggarwal >> Sent: zaterdag 6 februari 2010 1:00 >> To: Loa Andersson >> Cc: mpls@ietf.org; mpls-tp@ietf.org >> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10 >> >> >> Here are my LC comments on draft-ietf-mpls-tp-framework-10, >> prefixed by >> <RA>: >> >> >> 1. 1.3.4. MPLS-TP Label Switched Path >> >> An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a >> subset of the capabilities of an MPLS LSP in order to meet the >> requirements of an MPLS transport network as set out in [RFC5654]. >> The characteristics of an MPLS-TP LSP are primarily that it: >> >> <RA> I would suggest adding: "A MPLS-TP LSP is the lowest >> server layer provided by MPLS-TP. The client layers of a >> MPLS-TP LSP maybe IP, MPLS or PWs. The client layers of a >> MPLS-TP LSP are described in detail in section 3.4" >> >> This is to make the client server relationship in MPLS-TP clearer. >> >> 2. 1.3.10. Additional Definitions and Terminology >> >> Detailed definitions and additional terminology may be found in >> [RFC5654]. >> >> <RA> I would suggest a section on "Service Interface". This >> is to clarify the applicability of the use of MPLS-TP LSPs >> and PWs as described in section 3.4. Furhter it is needed to >> clarify what is the interface exposed by MPLS-TP to the >> client network. >> >> "Service Interface >> >> The transport service provided by MPLS-TP is said to be >> provided by a service interface. The following are the >> service interfaces supported by >> MPLS-TP: >> >> - The service interface may a layer 2 interface that carries >> only network layer clients. MPLS-TP LSPs are both necessary >> and sufficient to support this service interface as described >> in section 3.4.3 >> >> - Or the service interface may be a layer 2 interface that >> carries both network layer and non-network layer clients. To >> support this service interface, a PW is required to adapt the >> client traffic received over the service interface. This PW >> in turn is a client of the MPLS-TP server layer. >> This is described in section 3.4.2. >> >> - Or the service interface may be a MPLS LSP or a PW. To >> support this case a MPLS-TP PE participates in the service >> interface signaling." >> >> 3. 1.4. Applicability >> >> MPLS-TP can be used to construct packet transport networks and is >> therefore applicable in any packet transport network >> context. It is >> also applicable to subsets of a packet network where the transport >> network operational model is deemed attractive. The following are >> examples of MPLS-TP applicability models: >> >> 1. MPLS-TP provided by a network that only supports >> MPLS-TP LSPs and >> PWs (i.e. Only MPLS-TP LSPs and PWs exist between the PEs or >> LSRs), acting as a server for other layer 1, layer 2 >> and layer 3 >> networks (Figure 1). >> >> 2. MPLS-TP provided by a network that also supports >> non-MPLS-TP LSPs >> and PWs (i.e. both LSPs and PWs that conform to the transport >> profile and those that do not, exist between the PEs), >> acting as >> a server for other layer 1, layer 2 and layer 3 networks >> (Figure 2). >> >> 3. MPLS-TP as a server layer for client layer traffic of >> IP or MPLS >> networks which do not use functions of the MPLS transport >> profile. For MPLS traffic, the MPLS-TP server layer >> network uses >> PW switching [RFC5659] or LSP stitching [RFC5150] at >> the PE that >> terminates the MPLS-TP server layer (Figure 3). >> >> >> <RA> I think figure 3 and case 3 as written currently are >> making an assumption that a MPLS-TP PE participates in the >> "service interface signaling" where the service interface >> provided by MPLS-TP is a MPLS LSP or a PW. This is a NNI >> model. Perhaps we need two sub-cases of case 3. >> One is a UNI model where the MPLS network just sees a P2P or >> P2MP link, which is provided by the MPLS-TP network. In this >> case mechanisms of section >> 3.4.3 are sufficient. The second case is the one which the >> current text seems to imply and in that case the MPLS-TP PE >> would participate in the MPLS signaling. In this case the >> MPLS-TP PE may use LSP hierarchy or LSP stitching to support >> the MPLS-LSP as a service interface and may use PW stitching >> to support PW as a service interface. >> >> <RA> So I would propose to replace example number 3 above with: >> >> "3. MPLS-TP as a server layer for client layer traffic of >> IP or MPLS >> networks which do not use functions of the MPLS transport >> profile. Here are two examples of applicability models of this: >> >> a) The client IP or MPLS network is provided a layer 2 P2P or >> P2MP link by the MPLS-TP network. In other words the service >> interface is a layer 2 inteface that carries only IP or MPLS >> packets. To support this case the MPLS-TP server >> layer network uses >> the mechanisms of section 3.4.3 to carry IP or MPLS client l >> layer traffic over MPLS-TP LSPs" >> >> b) The client IP or MPLS network is provided a LSP or a PW as a >> service interface by the MPLS-TP network. In this case >> the MPLS-TP PE would participate in the client MPLS >> signaling. >> In this case the MPLS-TP PE may use LSP hierarchy or LSP >> stitching to support the MPLS-LSP as a service interface and >> may use PW stitching to support PW as a service interface >> (Figure 3)" >> >> 4. 3.1 Packet Transport Services >> >> One objective of MPLS-TP is to enable MPLS networks to >> provide packet >> transport services with a similar degree of predictability to that >> found in existing transport networks. Such packet >> transport services >> inherit a number of characteristics, defined in [RFC5654]: >> >> o In an environment where an MPLS-TP layer network is supporting a >> client layer network, and the MPLS-TP layer network is supported >> by a server layer network then operation of the MPLS-TP layer >> network must be possible without any dependencies on either the >> server or client layer network. >> >> o The service provided by the MPLS-TP network to the client is >> guaranteed not to fall below the agreed level >> regardless of other >> client activity. >> >> o The control and management planes of any client network >> layer that >> uses the service is isolated from the control and management >> planes of the MPLS-TP layer network, where the client network >> layer is considered to be the native service of the MPLS-TP >> network. >> >> o Where a client network makes use of an MPLS-TP server that >> provides a packet transport service, the level of co-ordination >> required between the client and server layer networks is minimal >> (preferably no co-ordination will be required). >> >> o The complete set of packets generated by a client >> MPLS(-TP) layer >> network using the packet transport service, which may contain >> packets that are not MPLS packets (e.g. IP or CLNS packets used >> by the control/management plane of the client MPLS(-TP) layer >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 12] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> network), are transported by the MPLS-TP server layer network. >> >> o The packet transport service enables the MPLS-TP layer network >> addressing and other information (e.g. topology) to be >> hidden from >> any client layer networks using that service, and vice-versa. >> >> These characteristics imply that a packet transport >> service does not >> support a connectionless packet-switched forwarding mode. However, >> this does not preclude it carrying client traffic associated with a >> connectionless service. >> >> Such packet transport services are very similar to Layer 2 Virtual >> Private Networks as defined by the IETF. >> >> <RA> The last sentence should be deleted. It doesn't add >> value and is in potential conflict with section 3.4.3. >> >> >> 5. 3.3. Architecture >> >> MPLS-TP comprises the following architectural elements: >> >> o A standard MPLS data plane [RFC3031] as profiled in >> [I-D.fbb-mpls-tp-data-plane]. >> >> <RA> Standard MPLS data plane also includes RFC 5331 and RFC 5332. >> Given draft-fbb is not a WG draft, I don't think we should >> add a reference to it here. >> >> >> 6. 3.4.2. Pseudowire Adaptation >> >> The architecture for an MPLS-TP network that provides PW emulated >> services is based on the MPLS [RFC3031] and pseudowire [RFC3985] >> architectures. >> >> <RA> I think instead of "PW emulated services", the section >> should start with the service interface that requires PWs. >> Something like: >> >> "If the MPLS-TP network provides a layer 2 interface, that >> carries both network layer and non-network layer traffic, as >> a service interface then a PW is required to support the >> service interface. >> The PW is a client of the MPLS-TP LSP server layer. The >> architecture of a MPLS-TP network that uses such PWs is is >> based on the MPLS [RFC3031] and pseudowire [RFC3985] architectures." >> >> <RA> The above is to make it very clear the applicability of >> 3.4.2 as compared to 3.4.3. >> >> Multi-segment pseudowires may optionally be used to >> provide a packet transport service, and their use is >> consistent with >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 18] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> the MPLS-TP architecture. The use of MS-PWs may be >> motivated by, for >> example, the requirements specified in [RFC5254]. If MS-PWs are >> used, then the MS-PW architecture [RFC5659] also applies. >> >> Figure 6 shows the architecture for an MPLS-TP network >> using single- >> segment PWs. >> >> |<--------------- Emulated Service ----------------->| >> | | >> | |<-------- Pseudowire -------->| | >> | | encapsulated, packet | | >> | | transport service | | >> | | | | >> | | |<------ LSP ------->| | | >> | V V V V | >> V AC +----+ +-----+ +----+ AC V >> +-----+ | | PE1|=======\ /========| PE2| | >> +-----+ >> | |----------|.......PW1.| \ / >> |............|----------| | >> | CE1 | | | | | X | | | | >> | CE2 | >> | |----------|.......PW2.| / \ >> |............|----------| | >> +-----+ ^ | | |=======/ \========| | | >> ^ +-----+ >> ^ | +----+ +-----+ +----+ | ^ >> | | Provider Edge 1 ^ Provider Edge 2 | | >> | | | | | >> Customer | P Router >> | Customer >> Edge 1 | >> | Edge 2 >> | | >> | | >> Native service Native service >> >> >> Figure 6: MPLS-TP Architecture (Single Segment PW) >> >> Figure 7 shows the architecture for an MPLS-TP network when multi- >> segment pseudowires are used. Note that as in the SS-PW case, >> P-routers may also exist. >> >> <RA> This figure needs to clarify where the MPLS-TP PEs are >> and where the "service PEs" are. Or whether PE1 is actually >> both the MPLS-TP PE and the service PE. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 19] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> |<----------- Pseudowire encapsulated ------------->| >> | packet transport service | >> | | >> | | >> | | >> AC | |<-------- LSP1 -------->| |<--LSP2-->| | AC >> | V V V V V V | >> | +----+ +-----+ +----+ +----+ | >> +---+ | |TPE1|===============\ >> /=====|SPE1|==========|TPE2| | +---+ >> | |---|......PW1-Seg1.... | \ / | >> ......X...PW1-Seg2......|---| | >> |CE1| | | | | X | | | | >> | | |CE2| >> | |---|......PW2-Seg1.... | / \ | >> ......X...PW2-Seg2......|---| | >> +---+ | | |===============/ \=====| |==========| >> | | +---+ >> ^ +----+ ^ +-----+ +----+ ^ +----+ ^ >> | | ^ | | >> | TE LSP | TE LSP | >> | P-router | >> | | >> |<-------------------- Emulated Service ------------------->| >> >> PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while >> PW2-segment1 and PW2-segment2 are segments of another MS-PW >> >> >> Figure 7: MPLS-TP Architecture (Multi-Segment PW) >> >> The corresponding MPLS-TP protocol stacks including PWs >> are shown in >> Figure 8. In this figure the Transport Service Layer [RFC5654] is >> identified by the PW demultiplexer (Demux) label and the Transport >> Path Layer [RFC5654] is identified by the LSP Demux Label. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 20] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> +-------------------+ /===================\ >> /===================\ >> | Client Layer | H OAM PDU H H OAM >> PDU H >> /===================\ H-------------------H >> H-------------------H >> H PW Encap H H GACh H H >> GACh H >> H-------------------H H-------------------H >> H-------------------H >> H PW Demux (S=1) H H PW Demux (S=1) H H GAL >> (S=1) H >> H-------------------H H-------------------H >> H-------------------H >> H LSP Demux(s) H H LSP Demux(s) H H LSP >> Demux(s) H >> \===================/ \===================/ >> \===================/ >> | Server Layer | | Server Layer | | Server >> Layer | >> +-------------------+ +-------------------+ >> +-------------------+ >> >> User Traffic PW OAM LSP OAM >> >> Note: H(ighlighted) indicates the part of the protocol stack >> we are considering in this document. >> >> >> Figure 8: MPLS-TP Layer Network using Pseudowires >> >> PWs and their associated labels may be configured or signaled. See >> Section 3.11 for additional details related to configured service >> types. See Section 3.9 for additional details related to signaled >> service types. >> >> 7. 3.4.2.1. Pseudowire Based Services >> >> When providing a Virtual Private Wire Service (VPWS) , Virtual >> Private Local Area Network Service (VPLS), Virtual Private >> Multicast >> Service (VPMS) or Internet Protocol Local Area Network Service >> (IPLS), pseudowires must be used to carry the client >> service. VPWS, >> VLPS, and IPLS are described in [RFC4664]. VPMS is described in >> [I-D.ietf-l2vpn-vpms-frmwk-requirements]. >> >> <RA> This section should be deleted. From a MPLS-TP network >> view point the service interface, that requires PWs, is a >> point-to-point layer 2 interface that carries both network >> layer and non-network layer traffic. This is orthogonal to >> the service which is being delivered to the end user. Hence >> this section doesn't belong here. >> >> >> 8. 3.4.3. Network Layer Adaptation >> >> MPLS-TP LSPs can be used to transport network layer clients. This >> document uses the term Network Layer in the same sense as >> it is used >> in [RFC3031] and [RFC3032]. The network layer protocols >> supported by >> [RFC3031] and [RFC3032] can be transported between service >> interfaces. Examples are shown in Figure 5 above. Support for >> network layer clients follows the MPLS architecture for support of >> network layer protocols as specified in [RFC3031] and [RFC3032]. >> >> With network layer adaptation, the MPLS-TP domain provides either a >> uni-directional or bidirectional point-to-point connection between >> two PEs in order to deliver a packet transport service to attached >> customer edge (CE) nodes. For example, a CE may be an IP, MPLS or >> >> >> >> Bocci, et al. Expires August 8, 2010 >> [Page 21] >> >> Internet-Draft MPLS Transport Profile Framework >> February 2010 >> >> >> MPLS-TP node. As shown in Figure 9, there is an attachment circuit >> between the CE node on the left and its corresponding provider edge >> (PE) node which provides the service interface, a bidirectional LSP >> across the MPLS-TP network to the corresponding PE node on >> the right, >> and an attachment circuit between that PE node and the >> corresponding >> CE node for this service. >> >> The attachment circuits may be heterogeneous (e.g., any combination >> of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads >> arrive at the service interface encapsulated in the Layer1/Layer2 >> encoding defined for that access link type. It should be >> noted that >> the set of network layer protocols includes MPLS and hence MPLS >> encoded packets with an MPLS label stack (the client MPLS >> stack), may >> appear at the service interface. >> >> |<------------- Client Network Layer ------------->| >> | | >> | |<---- Pkt Xport Service --->| | >> | | | | >> | | |<-- PSN Tunnel -->| | | >> | V V V V | >> V AC +----+ +---+ +----+ AC V >> +-----+ | |PE1 | | | |PE2 | | >> +-----+ >> | | |LSP | | | | | | | >> | | >> | CE1 |----------| |========X=========| >> |----------| CE2 | >> | | ^ |IP | | ^ | | ^ | | | >> ^ | | >> +-----+ | | | | | | | | | | | >> | +-----+ >> ^ | +----+ | +---+ | +----+ | | ^ >> | | Provider | ^ | Provider | | >> | | Edge | | | Edge | | >> Customer | 1 | P-router | 2 >> | Customer >> Edge 1 | TE TE | Edge 2 >> | LSP LSP | >> | | >> Native service Native service >> >> >> Figure 9: MPLS-TP Architecture for Network Layer Clients >> >> <RA> PE1 and PE2 should be specifically labeled as MPLS-TP PEs. >> >> At the ingress service interface the client packets are received . >> The PE pushes one or more labels onto the client packets which are >> then label switched over the transport network. >> Correspondingly the >> egress PE pops any labels added by the MPLS-TP networks >> and transmits >> the packet for delivery to the attached CE via the egress service >> interface. >> >> 9. 3.6. Generic Associated Channel (G-ACh) >> >> For correct operation of the OAM it is important that the >> OAM packets >> fate-share with the data packets. In addition in MPLS-TP it is >> necessary to discriminate between user data payloads and >> other types >> of payload. For example, a packet may be associated with >> a Signaling >> Communication Channel (SCC), or a channel used for Automatic >> Protection Switching (APS) data. This is achieved by carrying such >> packets on a generic control channel associated to the LSP, PW or >> section. >> >> <RA> Suggest replacing the last sentence with: >> >> "This is achieved by either carrying such packets in an IP >> encapsulation that provides the necessary discrimination, or >> by carrying such packets on a generic control channel >> associated to the LSP, PW or section. Rest of this section >> describes the latter mechanism." >> >> <RA> Also please see related comment in section 3.7. >> >> >> 10. 3.7. Operations, Administration and Maintenance (OAM) >> >> MPLS-TP must be able to operate in environments where IP >> is not used >> in the forwarding plane. Therefore, the default mechanism for OAM >> demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated >> Channel (Section 3.6). Forwarding based on IP addresses >> for user or >> OAM packets is not required for MPLS-TP. >> >> [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] have defined >> alert mechanisms that enable an MPLS LSR to identify and >> process MPLS >> OAM packets when the OAM packets are encapsulated in an IP header. >> These alert mechanisms are based on TTL expiration and/or use an IP >> destination address in the range 127/8 for IPv4 and that same range >> embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. >> When the >> OAM packets are encapsulated in an IP header, these mechanisms are >> the default mechanisms for MPLS networks in general for identifying >> MPLS OAM packets. MPLS-TP must be able to operate in an >> environments >> where IP forwarding is not supported, and thus the G-ACh/GAL is the >> default mechanism to demultiplex OAM packets in MPLS-TP. >> >> <RA> The last sentence is in conflict with the following from section >> 4.1 of RFC 5586: >> >> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert mechanisms >> that enable an MPLS LSR to identify and process MPLS OAM >> packets when >> these are encapsulated in an IP header. These alert mechanisms are >> based, for example, on Time To Live (TTL) expiration and/or on the >> use of an IP destination address in the range of >> 127.0.0.0/8 or 0:0: >> 0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively. >> >> These mechanisms are the default mechanisms for >> identifying MPLS OAM >> packets when encapsulated in an IP header although the mechanism >> defined in this document MAY also be used." >> >> <RA> Hence the last sentence of the above paragraph must be removed. >> >> >> rahul >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> >> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > > >
- [mpls] Working Group last call on draft-ietf-mpls… Loa Andersson
- Re: [mpls] [mpls-tp] Working Group last call on d… Loa Andersson
- [mpls] LC comments on draft-ietf-mpls-tp-framewor… Rahul Aggarwal
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… Maarten Vissers
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… neil.2.harrison
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… Lou Berger
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… neil.2.harrison
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… Lou Berger
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… neil.2.harrison
- Re: [mpls] [mpls-tp] LC comments on draft-ietf-mp… Maarten Vissers