From rajiva@cisco.com Sun Apr 1 03:20:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEAA21F86A0 for ; Sun, 1 Apr 2012 03:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zny8vxKQ83Sx for ; Sun, 1 Apr 2012 03:20:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9AE21F8617 for ; Sun, 1 Apr 2012 03:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=42446; q=dns/txt; s=iport; t=1333275619; x=1334485219; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=DT9SEaDOc86Lxi+3ymlwGNqBxMHcyaDV3HyaisDSswQ=; b=OhLMkw+P5C2PfSHx23G2iAiVNDrfTg2jkAUQUAfRjNFjeHqEyPLnk9/e UQxPRaE6j7ofwjxhrnj3MKL/HA0CWqnvYjIcp28FVITx+fdAyTbbIPB7z AMmonC9pmgculq7d4g+mbamt1CYPJgo7/359MKWO4ihrJT6OIvY7vA+R6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAkreE+tJV2c/2dsb2JhbABDuQqBB4IJAQEBAwEBAQEPAQcBFQotBQIEBAMMBgEIEQQBAQEKBhcBByYfCQkBBBMIARIHh2IFC6AUljKLGoUfYwSIWIJiiziFS4drgWiDBYE2AgU X-IronPort-AV: E=Sophos;i="4.75,352,1330905600"; d="scan'208";a="71143025" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 01 Apr 2012 10:20:18 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q31AKH6Q029779; Sun, 1 Apr 2012 10:20:17 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 05:20:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2012 05:20:15 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3g== From: "Rajiv Asati (rajiva)" To: "Shah, Himanshu" X-OriginalArrivalTime: 01 Apr 2012 10:20:17.0421 (UTC) FILETIME=[08E283D0:01CD0FF1] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 10:20:22 -0000 Hi Himanshu,=20 Appreciate your question. There are at least two benefits for sending IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack interface if enabled with both LDP IPv4 and LDP IPv6: =09 1. Discovering v4 or/and v6 transport that the peer is willing to use for bootstrapping the subsequent TCP session (and resorting to using the alternate transport if the preferred one failed) Similar to that of happy eyeball (unless hardcoded or got into collision)!=20 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as the routing next-hops Please see section 8 for more details http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 While it may be tempting to maintain only one hello adj (IPv4, say) (that got used to establish the subsequent (IPv4, say) TCP/LDP session) and let go of the other hello adj (IPv6, say) that didn't get used, it could cause traffic blackholing (due to missing #2 above) for packets going on LSPv6. Does this clarify? Cheers, Rajiv > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Wednesday, March 28, 2012 4:06 PM > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > I second the same concern and fail to understand the rationale to bypass the > available > tool (capacity negotiation). > Thanks, > himanshu >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Wednesday, March 28, 2012 3:56 PM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Rajiv, > I am afraid we are not making progress on the technical questions I raised on > this draft. >=20 > For the benefit of everyone else on the mailing list, I am going to state the > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. This > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) which can be > resolved in the datapath over a given link based on the type of the control > plane adjacency (IPv4 or IPv6) established over that link. This coupling of FEC > resolution to the type of control plane adjacency is not correct and breaks so > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC type between > peers is independent of the adjacency established. >=20 > In addition, this proposal now means that we need 2 link Hello adjacencies over > each link and 2 targeted Hello adjacencies between any two LSR nodes. This is > not good from a scaling perspective while it provides no gain. >=20 > In an earlier exchange on this thread, we discussed the need for introducing > per Hello adjacency capability negotiation to address the probem of which FEC > types can be resolved over a given link adjacency. That is the correct approach > to the problem and we should keep the behaviour of RFC 5036 as is, that is an > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an IPv6 link > adjacency will bootstrap an IPv6 LDP session. There is no need or value for two > link Hellos associating with the same IPv4 or IPv6 LDP session. >=20 > Regards, > Mustapha. >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 12:25 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 >=20 > Hi Mustapha, >=20 > Thanks for the discussion. Please see inline, >=20 > 1. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. >=20 >=20 > 2. > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. >=20 > It is not about the FEC. It is about the LSP, and rightfully so. >=20 > Hopefully, answering this Q will help us - If there are 3 links (LDP > enabled) between two LSRs and only two have hello adj leading to the working > LDP session, then would the LSRs use the 3rd link (which doesn't have valid > hello adj) for MPLS packet forwarding? >=20 > - If your answer is Yes, then we have a fundamental disagreement independent > of LDP IPv6. > - If the answer is No, then that's inline with what's described in the last para of > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > Perhaps, the text needs a bit of rephrasing, so please feel free to suggest. >=20 > The above has no bearing on FEC type e.g. IPv4 packet being sent over > LSPv6 or vice versa. >=20 > Hence, we leave the text as-it-is. >=20 >=20 > 3. >=20 > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. >=20 > Removing last paragraph of section 2.5.2 from RFC 5036 ? >=20 > That would fundamentally break RFC5036. >=20 >=20 > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. >=20 > Correct and that's because each LSR uses the same LDP Identifier and qualifies > for the point 1 of section 2.5.2 in RFC5036, which suggests to not establish a > new session if there is already one existing using the same LDP Identifier: >=20 > // > 1. If LSR1 does not already have an LDP session for the exchange > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // >=20 >=20 > > It becomes an issue of association of multiple Hello adjacencies with > > a single TCP connection. >=20 > And it is not an issue thanks to the last para of section 2.5.2. We can NOT afford > to remove it. >=20 > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. >=20 >=20 > 4. > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. >=20 > That's incorrect. As you know, PW-FEC, as per RFC5036, already requires > 'extended/targetted hello adj', not 'basic hello adj' with the peer before > exchanging PW-FECs with that peer. >=20 > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is > enabled on an interface. This is already implicit in RFC5036. > And if the interface is a dual-stack interface, then the behavior shouldn't > change. >=20 >=20 > 5. > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. >=20 > Well, RFC5036 (LDP version 1) prescribes using a single session for exchanging > FEC-label bindings for various FEC types. >=20 > We could work on version 2 to move away from that intention e.g. allow using > more than one session between two LSRs. >=20 > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. >=20 > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > exchanged, as permitted. > We are in agreement here. >=20 > 6. > Given the lack of response for #6, I am assuming this we have agreed and > closed the discussion on this point. Thanks. >=20 > 7. >=20 > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a >=20 > Please see my response to #4. Nonetheless, this is moot, as it is a MAY, and is > local to the LSR. > FWIW, this point has been beaten to death last yr, and I would urge you to > check the discussion on the mailing list from last yr. >=20 > 8. >=20 > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? >=20 > If the node still receives the unsupported FEC or address type, then it indicates > that the peer has a bug, and it should follow the behavior specified in RFC5036 > e.g. declare a fatal error. >=20 > This is orthogonal to capability or FEC filter, since the assumption here is that > an LSR is willing to send/receive FEC-label bindings for both IPv4 and IPv6 and > more. The point is that the loophole that has existed all along is closed when an > LSR gets upgraded with the code compliant with this specification. >=20 > 9. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. >=20 > 10. >=20 > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. >=20 > You do make a good point about us not changing the LDP protocol version, so, it > is not a new protocol, and I agree. > I will consider to change GTSM to optional (MAY), subjected to Carlos's opinion. >=20 > We will revisit it if/when the consensus suggests otherwise prior to RFC > publication. > We can close this point as well. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Friday, March 02, 2012 1:09 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > See some follow-up inline. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Wednesday, February 29, 2012 10:28 PM > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the review of the document and the feedback. It is never > too late. > > :) Sorry about the delay in getting back to you. > > > > Please see inline, > > > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > Yes, they were discussed in the past and closed. > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > No. > > > > While it is a common practice to assign a host route to the loopback > interface, > > and it is a common practice to use loopback interface as the next-hop, > we > > must not assume the common practice to be the norm for the protocol. > In > > fact, there is NO technical argument against using the non-host route > on a > > loopback interface. > > > > In fact, almost every implementation allows the next-hop to be a > non-host > > route, and I am aware of at least one implementation that allows LDP > to > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if > hello adj > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > forwarding on that interface. So, if IPv6 hello adj failed, then stop > the IPv6 > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > blindly > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > // > > when it receives a Hello that matches the adjacency. If the timer > > expires without receipt of a matching Hello from the peer, LDP > > concludes that the peer no longer wishes to label switch using that > > label space for that link (or target, in the case of Targeted > Hellos) > > or that the peer has failed. The LSR then deletes the Hello // > > > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > > I agree. It doesn't have anything to do with the address family, but > it > > becomes restrictive when having to accommodate transport of two > different > > address families (IPv4 and IPv6). Pls see more details on this later > on. > > > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > That's not correct (and the implementation is in violation of > RFC5036). > > > > We had good discussion on this early on. In fact, we had an editor's > note on > > this in initial versions of this document to solicit discussion on > that. > > > > The last para of section 2.5.2, as stated, would result in a > particular IP address > > (1.1.1.1, say) being encoded in the transport address in both > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > (which is > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > from > > carrying IPv6 transport address (or IPv4 hello from carrying > > IPv4 transport address). It would not make sense. > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > address > > and vice versa. It wouldn't make sense and would be incorrect. > > > > That's why the change was needed. > > > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. It becomes an issue of association of multiple > Hello > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > We thought so too, but we uncovered various corner cases in which this > > becomes problematic, not to mention that the indeterminism it would > bring > > into the picture. The easiest was to maintain hello adj per > address-family per > > peer. > > > > For ex, consider three LDP enabled interfaces between R1 and R2, where > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > maintain only > > single adj, then they would have hello adj of one transport (v6, say) > on dual- > > stack interfaces, and another transport (v4, > > say) on 3rd interface. > > > > Hello adj is tightly coupled with the functional LDP peering. If (the > > last) hello adj is lost, then LDP peering must be brought down. > > Additionally, if hello adj is gone from an interface, then LDP should > prohibit > > MPLS forwarding from using that interface. > > > > Another way to think about it is - if IPv4 stops functioning on an > interface, but > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > penalized. > > And vice versa. > > > > Having separate hello adj maintenance is much cleaner/simpler and > provides > > deterministic behavior. > > > > Nonetheless, an implementation could choose to optimize, if needed, to > > keep both address-family related info in a single adjacency structure, > but this > > is all implementation specific. :) > > > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > Good point, but this is a different problem. It is not about the > sequence > > (which was ok if IPv4 hellow as carrying two IPv4 transport > addresses). > > > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > > transport address is fundamentally a wrong approach, IMO. How would > IPv4 > > know that IPv6 transport is even functional (and vice versa). IPv4 > based > > discovery should suggest IPv4 transport, and IPv6 based discovery > should > > suggest IPv6 transport. > > > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > > connection and vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > We need the address-family awareness in peer hello adjacency/s, > whether it > > is a kept in a single adj structure or not. > > > > Loosing the AFI awareness leads up the other problems that I mentioned > > earlier. > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > It is MAY. :) > > It was changed to MAY based on the exhaustive discussion on mailing > list in > > 2011 for us to move forward. > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > > different protocol. > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > We initially thought so too, until we discovered the following very > explicitly in > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > // > > Section 3.5.5.1 - > > If an LSR does not support the Address Family specified in the Address > List=09 > > TLV, it SHOULD send an Unsupported Address Family Notification to its > LDP > > signaling an error and abort processing the message. > > > > Section 3.4.1.1 - > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address > > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > > processing the message containing the TLV, and send an "Unsupported > > Address Family" Notification message to its LDP peer signaling an > error. > > // > > > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > Because it is native in IPv6 to allow for link-local addresses that > IPv4 never > > allowed. > > So, what was an anomaly with IPv4 is now a standard behavior with > IPv6, > > hence, that verbiage. > > > > > > > > 10. Section 9 - LDP TTL Security > > > > " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > We posed the Q about GTSM being the default or not during IETF 80, and > > there were 10-yes and 0-no (mostly from operators) Pls see the > minutes, > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Monday, February 06, 2012 3:21 PM > > > To: Shane Amante > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Shane, > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > LDP > > session > > > from a peer which is identified by the LDP identifier tuple {LSR-id, > > label-space- > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > different label > > > spaces, then they must use two different Hello adjacencies and LDP > > sessions for > > > that. Also, if an implementation supports virtualization of LDP, > then > > a different > > > LDP identifier altogether can be used to establish a separate LDP > > session. Other > > > than that, there is no relation between the type of adjacency and > the > > FEC which > > > are carried. For example, the same LDP Hello Adjacency and LDP > session > > are > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > between > > two > > > directly connected peers. > > > > > > As far as I know BGP is not very different. It offers the ability to > > carry IPv4 NLRI > > > over a IPv6 session and vice versa. > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > IPv4 > > on an IPv4 > > > session between two LSRs, then we should consider extending RFC > 5036 > > to > > > allow for two different LSR-id values sharing the same global label > > space. This > > > way, we can have separate Hello adjacency and LDP session and it is > up > > to the > > > user to assign which FEC type is allowed on which LDP session. This > is > > a new > > > work item but in my view much cleaner and backward compatible with > RFC > > > 5036 than to try to tie the address family to the type of Hello > > adjacency. > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > Hello > > > adjacency but a single shared LDP session. It is not exactly what > you > > are asking > > > for. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > Sent: Friday, February 03, 2012 11:32 PM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mustapha, > > > > > > I am not an author, but I do want to provide some operational input > on > > some of > > > your comments. Specifically, I get the sense from several of your > > comments -- > > > actually, moreso from #3 -- that you are opposed to maintaining > > separate LDP > > > Hello and/or Session Adjacencies: 1 for each address family. (If my > > impression > > > is incorrect I apologize). > > > > > > I actually *do* want to have separate LDP Hello and Session > > adjacencies: one > > > per address family, at least at this point in time. I'm concerned > > about > > > [operational] issues that may develop in, for example, v6 affecting > > the > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > one > > more > > > concrete example, 6man/v6ops are only right now working on improving > > the > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > areas where > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > problems in v6 > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > FWIW, there has > > > already been a precedent here wrt BGP where there it maintains > > separate > > > neighbors/sessions for each address family, so why aren't we doing > the > > same > > > thing for LDP? > > > > > > Ultimately, having separate sessions over-the-wire is much more > > intuitive to > > > operators in lots of cases where they may expect that a > configuration > > change > > > or bugs they /think/ are only going to affect one address family, > > really do only > > > affect one address family. Besides, LDP Hello & Sessions timers, > when > > set to > > > default, are extremely relaxed (order of several seconds), so the > > burden on > > > implementations to maintain separate sessions should be miniscule. > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > over the > > > wire to avoid "fate sharing". Only when an operator chooses to > > explicitly > > > configure their device to have hellos and sessions share fate should > > the device > > > do so. > > > > > > Just my $0.02, > > > > > > -shane > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > Dear authors, > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > > > > > > > > > 10. Section 9 - LDP TTL Security > > > > " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From prvs=94384ee8c8=hshah@ciena.com Sun Apr 1 04:59:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE6E21F8645 for ; Sun, 1 Apr 2012 04:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCN-AyAM4GTw for ; Sun, 1 Apr 2012 04:59:39 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE421F861B for ; Sun, 1 Apr 2012 04:59:38 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q31BtQEB020791; Sun, 1 Apr 2012 07:59:34 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 13xmu4gd6q-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 01 Apr 2012 07:59:33 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Sun, 1 Apr 2012 07:59:33 -0400 From: "Shah, Himanshu" To: "Rajiv Asati (rajiva)" Date: Sun, 1 Apr 2012 07:59:30 -0400 Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3gAEsG7w Message-ID: References: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18810.006 x-tm-as-result: No--23.967800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-03-31_07:2012-03-30, 2012-03-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204010085 Cc: "Aissaoui, Mustapha \(Mustapha\)" , "mpls@ietf.org" Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 11:59:42 -0000 Thanks Rajiv. It does clarify for me. Can you also clarify that this is limited to link hello and not applicable to targeted hello, especially the LDP adjacencies/sessions we use for PW signaling (as they tend to have +many+ LDP peers!!) rgds, Himanshu -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Sunday, April 01, 2012 6:20 AM To: Shah, Himanshu Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-iet= f-mpls-ldp-ipv6-06) Hi Himanshu, Appreciate your question. There are at least two benefits for sending IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack interface if enabled with both LDP IPv4 and LDP IPv6: 1. Discovering v4 or/and v6 transport that the peer is willing to use for bootstrapping the subsequent TCP session (and resorting to using the alternate transport if the preferred one failed) Similar to that of happy eyeball (unless hardcoded or got into collision)! 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as the routing next-hops Please see section 8 for more details http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 While it may be tempting to maintain only one hello adj (IPv4, say) (that got used to establish the subsequent (IPv4, say) TCP/LDP session) and let go of the other hello adj (IPv6, say) that didn't get used, it could cause traffic blackholing (due to missing #2 above) for packets going on LSPv6. Does this clarify? Cheers, Rajiv > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Wednesday, March 28, 2012 4:06 PM > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > I second the same concern and fail to understand the rationale to bypass the > available > tool (capacity negotiation). > Thanks, > himanshu > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Wednesday, March 28, 2012 3:56 PM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Rajiv, > I am afraid we are not making progress on the technical questions I raised on > this draft. > > For the benefit of everyone else on the mailing list, I am going to state the > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. This > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) which can be > resolved in the datapath over a given link based on the type of the control > plane adjacency (IPv4 or IPv6) established over that link. This coupling of FEC > resolution to the type of control plane adjacency is not correct and breaks so > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC type between > peers is independent of the adjacency established. > > In addition, this proposal now means that we need 2 link Hello adjacencies over > each link and 2 targeted Hello adjacencies between any two LSR nodes. This is > not good from a scaling perspective while it provides no gain. > > In an earlier exchange on this thread, we discussed the need for introducing > per Hello adjacency capability negotiation to address the probem of which FEC > types can be resolved over a given link adjacency. That is the correct approach > to the problem and we should keep the behaviour of RFC 5036 as is, that is an > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an IPv6 link > adjacency will bootstrap an IPv6 LDP session. There is no need or value for two > link Hellos associating with the same IPv4 or IPv6 LDP session. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 12:25 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Mustapha, > > Thanks for the discussion. Please see inline, > > 1. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > > 2. > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. > > It is not about the FEC. It is about the LSP, and rightfully so. > > Hopefully, answering this Q will help us - If there are 3 links (LDP > enabled) between two LSRs and only two have hello adj leading to the working > LDP session, then would the LSRs use the 3rd link (which doesn't have valid > hello adj) for MPLS packet forwarding? > > - If your answer is Yes, then we have a fundamental disagreement independent > of LDP IPv6. > - If the answer is No, then that's inline with what's described in the last para of > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > Perhaps, the text needs a bit of rephrasing, so please feel free to suggest. > > The above has no bearing on FEC type e.g. IPv4 packet being sent over > LSPv6 or vice versa. > > Hence, we leave the text as-it-is. > > > 3. > > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. > > Removing last paragraph of section 2.5.2 from RFC 5036 ? > > That would fundamentally break RFC5036. > > > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. > > Correct and that's because each LSR uses the same LDP Identifier and qualifies > for the point 1 of section 2.5.2 in RFC5036, which suggests to not establish a > new session if there is already one existing using the same LDP Identifier: > > // > 1. If LSR1 does not already have an LDP session for the exchange > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > > > > It becomes an issue of association of multiple Hello adjacencies with > > a single TCP connection. > > And it is not an issue thanks to the last para of section 2.5.2. We can NOT afford > to remove it. > > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. > > > 4. > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. > > That's incorrect. As you know, PW-FEC, as per RFC5036, already requires > 'extended/targetted hello adj', not 'basic hello adj' with the peer before > exchanging PW-FECs with that peer. > > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is > enabled on an interface. This is already implicit in RFC5036. > And if the interface is a dual-stack interface, then the behavior shouldn't > change. > > > 5. > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. > > Well, RFC5036 (LDP version 1) prescribes using a single session for exchanging > FEC-label bindings for various FEC types. > > We could work on version 2 to move away from that intention e.g. allow using > more than one session between two LSRs. > > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. > > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > exchanged, as permitted. > We are in agreement here. > > 6. > Given the lack of response for #6, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > 7. > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > > Please see my response to #4. Nonetheless, this is moot, as it is a MAY, and is > local to the LSR. > FWIW, this point has been beaten to death last yr, and I would urge you to > check the discussion on the mailing list from last yr. > > 8. > > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? > > If the node still receives the unsupported FEC or address type, then it indicates > that the peer has a bug, and it should follow the behavior specified in RFC5036 > e.g. declare a fatal error. > > This is orthogonal to capability or FEC filter, since the assumption here is that > an LSR is willing to send/receive FEC-label bindings for both IPv4 and IPv6 and > more. The point is that the loophole that has existed all along is closed when an > LSR gets upgraded with the code compliant with this specification. > > 9. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > 10. > > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. > > You do make a good point about us not changing the LDP protocol version, so, it > is not a new protocol, and I agree. > I will consider to change GTSM to optional (MAY), subjected to Carlos's opinion. > > We will revisit it if/when the consensus suggests otherwise prior to RFC > publication. > We can close this point as well. > > Cheers, > Rajiv > > > -----Original Message----- > > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Friday, March 02, 2012 1:09 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > See some follow-up inline. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Wednesday, February 29, 2012 10:28 PM > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the review of the document and the feedback. It is never > too late. > > :) Sorry about the delay in getting back to you. > > > > Please see inline, > > > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > Yes, they were discussed in the past and closed. > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > No. > > > > While it is a common practice to assign a host route to the loopback > interface, > > and it is a common practice to use loopback interface as the next-hop, > we > > must not assume the common practice to be the norm for the protocol. > In > > fact, there is NO technical argument against using the non-host route > on a > > loopback interface. > > > > In fact, almost every implementation allows the next-hop to be a > non-host > > route, and I am aware of at least one implementation that allows LDP > to > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if > hello adj > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > forwarding on that interface. So, if IPv6 hello adj failed, then stop > the IPv6 > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > blindly > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > // > > when it receives a Hello that matches the adjacency. If the timer > > expires without receipt of a matching Hello from the peer, LDP > > concludes that the peer no longer wishes to label switch using that > > label space for that link (or target, in the case of Targeted > Hellos) > > or that the peer has failed. The LSR then deletes the Hello // > > > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > > I agree. It doesn't have anything to do with the address family, but > it > > becomes restrictive when having to accommodate transport of two > different > > address families (IPv4 and IPv6). Pls see more details on this later > on. > > > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > That's not correct (and the implementation is in violation of > RFC5036). > > > > We had good discussion on this early on. In fact, we had an editor's > note on > > this in initial versions of this document to solicit discussion on > that. > > > > The last para of section 2.5.2, as stated, would result in a > particular IP address > > (1.1.1.1, say) being encoded in the transport address in both > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > (which is > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > from > > carrying IPv6 transport address (or IPv4 hello from carrying > > IPv4 transport address). It would not make sense. > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > address > > and vice versa. It wouldn't make sense and would be incorrect. > > > > That's why the change was needed. > > > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. It becomes an issue of association of multiple > Hello > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > We thought so too, but we uncovered various corner cases in which this > > becomes problematic, not to mention that the indeterminism it would > bring > > into the picture. The easiest was to maintain hello adj per > address-family per > > peer. > > > > For ex, consider three LDP enabled interfaces between R1 and R2, where > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > maintain only > > single adj, then they would have hello adj of one transport (v6, say) > on dual- > > stack interfaces, and another transport (v4, > > say) on 3rd interface. > > > > Hello adj is tightly coupled with the functional LDP peering. If (the > > last) hello adj is lost, then LDP peering must be brought down. > > Additionally, if hello adj is gone from an interface, then LDP should > prohibit > > MPLS forwarding from using that interface. > > > > Another way to think about it is - if IPv4 stops functioning on an > interface, but > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > penalized. > > And vice versa. > > > > Having separate hello adj maintenance is much cleaner/simpler and > provides > > deterministic behavior. > > > > Nonetheless, an implementation could choose to optimize, if needed, to > > keep both address-family related info in a single adjacency structure, > but this > > is all implementation specific. :) > > > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > Good point, but this is a different problem. It is not about the > sequence > > (which was ok if IPv4 hellow as carrying two IPv4 transport > addresses). > > > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > > transport address is fundamentally a wrong approach, IMO. How would > IPv4 > > know that IPv6 transport is even functional (and vice versa). IPv4 > based > > discovery should suggest IPv4 transport, and IPv6 based discovery > should > > suggest IPv6 transport. > > > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > > connection and vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > We need the address-family awareness in peer hello adjacency/s, > whether it > > is a kept in a single adj structure or not. > > > > Loosing the AFI awareness leads up the other problems that I mentioned > > earlier. > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > It is MAY. :) > > It was changed to MAY based on the exhaustive discussion on mailing > list in > > 2011 for us to move forward. > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > > different protocol. > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > We initially thought so too, until we discovered the following very > explicitly in > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > // > > Section 3.5.5.1 - > > If an LSR does not support the Address Family specified in the Address > List > > TLV, it SHOULD send an Unsupported Address Family Notification to its > LDP > > signaling an error and abort processing the message. > > > > Section 3.4.1.1 - > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address > > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > > processing the message containing the TLV, and send an "Unsupported > > Address Family" Notification message to its LDP peer signaling an > error. > > // > > > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > Because it is native in IPv6 to allow for link-local addresses that > IPv4 never > > allowed. > > So, what was an anomaly with IPv4 is now a standard behavior with > IPv6, > > hence, that verbiage. > > > > > > > > 10. Section 9 - LDP TTL Security > > > > " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > We posed the Q about GTSM being the default or not during IETF 80, and > > there were 10-yes and 0-no (mostly from operators) Pls see the > minutes, > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Monday, February 06, 2012 3:21 PM > > > To: Shane Amante > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Shane, > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > LDP > > session > > > from a peer which is identified by the LDP identifier tuple {LSR-id, > > label-space- > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > different label > > > spaces, then they must use two different Hello adjacencies and LDP > > sessions for > > > that. Also, if an implementation supports virtualization of LDP, > then > > a different > > > LDP identifier altogether can be used to establish a separate LDP > > session. Other > > > than that, there is no relation between the type of adjacency and > the > > FEC which > > > are carried. For example, the same LDP Hello Adjacency and LDP > session > > are > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > between > > two > > > directly connected peers. > > > > > > As far as I know BGP is not very different. It offers the ability to > > carry IPv4 NLRI > > > over a IPv6 session and vice versa. > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > IPv4 > > on an IPv4 > > > session between two LSRs, then we should consider extending RFC > 5036 > > to > > > allow for two different LSR-id values sharing the same global label > > space. This > > > way, we can have separate Hello adjacency and LDP session and it is > up > > to the > > > user to assign which FEC type is allowed on which LDP session. This > is > > a new > > > work item but in my view much cleaner and backward compatible with > RFC > > > 5036 than to try to tie the address family to the type of Hello > > adjacency. > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > Hello > > > adjacency but a single shared LDP session. It is not exactly what > you > > are asking > > > for. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > Sent: Friday, February 03, 2012 11:32 PM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mustapha, > > > > > > I am not an author, but I do want to provide some operational input > on > > some of > > > your comments. Specifically, I get the sense from several of your > > comments -- > > > actually, moreso from #3 -- that you are opposed to maintaining > > separate LDP > > > Hello and/or Session Adjacencies: 1 for each address family. (If my > > impression > > > is incorrect I apologize). > > > > > > I actually *do* want to have separate LDP Hello and Session > > adjacencies: one > > > per address family, at least at this point in time. I'm concerned > > about > > > [operational] issues that may develop in, for example, v6 affecting > > the > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > one > > more > > > concrete example, 6man/v6ops are only right now working on improving > > the > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > areas where > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > problems in v6 > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > FWIW, there has > > > already been a precedent here wrt BGP where there it maintains > > separate > > > neighbors/sessions for each address family, so why aren't we doing > the > > same > > > thing for LDP? > > > > > > Ultimately, having separate sessions over-the-wire is much more > > intuitive to > > > operators in lots of cases where they may expect that a > configuration > > change > > > or bugs they /think/ are only going to affect one address family, > > really do only > > > affect one address family. Besides, LDP Hello & Sessions timers, > when > > set to > > > default, are extremely relaxed (order of several seconds), so the > > burden on > > > implementations to maintain separate sessions should be miniscule. > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > over the > > > wire to avoid "fate sharing". Only when an operator chooses to > > explicitly > > > configure their device to have hellos and sessions share fate should > > the device > > > do so. > > > > > > Just my $0.02, > > > > > > -shane > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > Dear authors, > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > > > > > > > > > 10. Section 9 - LDP TTL Security > > > > " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Sun Apr 1 10:37:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33A121F883E for ; Sun, 1 Apr 2012 10:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzhESllFm2US for ; Sun, 1 Apr 2012 10:37:08 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5A37221F8835 for ; Sun, 1 Apr 2012 10:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46046; q=dns/txt; s=iport; t=1333301828; x=1334511428; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Io+hpfJmQ0hGWtrl/kf9xOxsGx4nQxHvQLL4zNBGhOw=; b=gCG2XOFHCOBBn5TRnx0r3OyAcLD7XDpkaoiw1NQUF7WRygNOwXG9n3q+ uw0+JrpUurYTWOHFcKMTV2LXD0Vz9XAPr5GMZGbWF76/R+NeoZycBfbA0 tO5bNMNxBGaRR69b4vgDBw1ESHJ1ntuGxM994hkqwY46NOkIVrJScJbIr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC6ReE+tJXG9/2dsb2JhbABEuH6BB4IJAQEBAwEBAQEPAQcBFQotBQIEBAMMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBBMIARIHh2IFC5s0ngqLChCFH2MEiFiCYos4hUuHa4FogwWBNgIF X-IronPort-AV: E=Sophos;i="4.75,353,1330905600"; d="scan'208";a="68156577" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 01 Apr 2012 17:37:07 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q31Hb7Ii016109; Sun, 1 Apr 2012 17:37:07 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 12:37:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2012 12:37:04 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07C99778@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3gAEsG7wAApjeJA= References: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> From: "Rajiv Asati (rajiva)" To: "Shah, Himanshu" X-OriginalArrivalTime: 01 Apr 2012 17:37:06.0803 (UTC) FILETIME=[0EE4D430:01CD102E] Cc: "Aissaoui, Mustapha \(Mustapha\)" , mpls@ietf.org Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 17:37:11 -0000 Hi Himanshu, Glad that we are in sync. You are right that neither of those two points apply to targeted hello/discovery (since peer IP address is known apriori). Cheers, Rajiv > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Sunday, April 01, 2012 8:00 AM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) >=20 > Thanks Rajiv. It does clarify for me. > Can you also clarify that this is limited to link hello and > not applicable to targeted hello, especially the LDP adjacencies/sessions > we use for PW signaling (as they tend to have +many+ LDP peers!!) >=20 > rgds, > Himanshu >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Sunday, April 01, 2012 6:20 AM > To: Shah, Himanshu > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) >=20 > Hi Himanshu, >=20 > Appreciate your question. There are at least two benefits for sending > IPv6 hello & IPv4 hello and maintaining hello adj for both on a > dual-stack interface if enabled with both LDP IPv4 and LDP IPv6: >=20 > 1. Discovering v4 or/and v6 transport that the peer is willing to use > for bootstrapping the subsequent TCP session (and resorting to using the > alternate transport if the preferred one failed) > Similar to that of happy eyeball (unless hardcoded or got into > collision)! >=20 > 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as > the routing next-hops > Please see section 8 for more details > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 >=20 > While it may be tempting to maintain only one hello adj (IPv4, say) > (that got used to establish the subsequent (IPv4, say) TCP/LDP session) > and let go of the other hello adj (IPv6, say) that didn't get used, it > could cause traffic blackholing (due to missing #2 above) for packets > going on LSPv6. >=20 > Does this clarify? >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Wednesday, March 28, 2012 4:06 PM > > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > I second the same concern and fail to understand the rationale to > bypass the > > available > > tool (capacity negotiation). > > Thanks, > > himanshu > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Wednesday, March 28, 2012 3:56 PM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > I am afraid we are not making progress on the technical questions I > raised on > > this draft. > > > > For the benefit of everyone else on the mailing list, I am going to > state the > > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. > This > > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) > which can be > > resolved in the datapath over a given link based on the type of the > control > > plane adjacency (IPv4 or IPv6) established over that link. This > coupling of FEC > > resolution to the type of control plane adjacency is not correct and > breaks so > > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC > type between > > peers is independent of the adjacency established. > > > > In addition, this proposal now means that we need 2 link Hello > adjacencies over > > each link and 2 targeted Hello adjacencies between any two LSR nodes. > This is > > not good from a scaling perspective while it provides no gain. > > > > In an earlier exchange on this thread, we discussed the need for > introducing > > per Hello adjacency capability negotiation to address the probem of > which FEC > > types can be resolved over a given link adjacency. That is the correct > approach > > to the problem and we should keep the behaviour of RFC 5036 as is, > that is an > > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an > IPv6 link > > adjacency will bootstrap an IPv6 LDP session. There is no need or > value for two > > link Hellos associating with the same IPv4 or IPv6 LDP session. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Monday, March 12, 2012 12:25 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the discussion. Please see inline, > > > > 1. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > > > 2. > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > It is not about the FEC. It is about the LSP, and rightfully so. > > > > Hopefully, answering this Q will help us - If there are 3 links (LDP > > enabled) between two LSRs and only two have hello adj leading to the > working > > LDP session, then would the LSRs use the 3rd link (which doesn't have > valid > > hello adj) for MPLS packet forwarding? > > > > - If your answer is Yes, then we have a fundamental disagreement > independent > > of LDP IPv6. > > - If the answer is No, then that's inline with what's described in the > last para of > > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > > Perhaps, the text needs a bit of rephrasing, so please feel > free to suggest. > > > > The above has no bearing on FEC type e.g. IPv4 packet being sent over > > LSPv6 or vice versa. > > > > Hence, we leave the text as-it-is. > > > > > > 3. > > > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > Removing last paragraph of section 2.5.2 from RFC 5036 ? > > > > That would fundamentally break RFC5036. > > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. > > > > Correct and that's because each LSR uses the same LDP Identifier and > qualifies > > for the point 1 of section 2.5.2 in RFC5036, which suggests to not > establish a > > new session if there is already one existing using the same LDP > Identifier: > > > > // > > 1. If LSR1 does not already have an LDP session for the exchange > > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP > // > > > > > > > It becomes an issue of association of multiple Hello adjacencies > with > > > a single TCP connection. > > > > And it is not an issue thanks to the last para of section 2.5.2. We > can NOT afford > > to remove it. > > > > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. > > > > > > 4. > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > That's incorrect. As you know, PW-FEC, as per RFC5036, already > requires > > 'extended/targetted hello adj', not 'basic hello adj' with the peer > before > > exchanging PW-FECs with that peer. > > > > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 > is > > enabled on an interface. This is already implicit in RFC5036. > > And if the interface is a dual-stack interface, then the behavior > shouldn't > > change. > > > > > > 5. > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. > > > > Well, RFC5036 (LDP version 1) prescribes using a single session for > exchanging > > FEC-label bindings for various FEC types. > > > > We could work on version 2 to move away from that intention e.g. allow > using > > more than one session between two LSRs. > > > > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > > vice-versa. There is no relationship whatsoever between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > > exchanged, as permitted. > > We are in agreement here. > > > > 6. > > Given the lack of response for #6, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 7. > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > > Please see my response to #4. Nonetheless, this is moot, as it is a > MAY, and is > > local to the LSR. > > FWIW, this point has been beaten to death last yr, and I would urge > you to > > check the discussion on the mailing list from last yr. > > > > 8. > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > If the node still receives the unsupported FEC or address type, then > it indicates > > that the peer has a bug, and it should follow the behavior specified > in RFC5036 > > e.g. declare a fatal error. > > > > This is orthogonal to capability or FEC filter, since the assumption > here is that > > an LSR is willing to send/receive FEC-label bindings for both IPv4 and > IPv6 and > > more. The point is that the loophole that has existed all along is > closed when an > > LSR gets upgraded with the code compliant with this specification. > > > > 9. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 10. > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > You do make a good point about us not changing the LDP protocol > version, so, it > > is not a new protocol, and I agree. > > I will consider to change GTSM to optional (MAY), subjected to > Carlos's opinion. > > > > We will revisit it if/when the consensus suggests otherwise prior to > RFC > > publication. > > We can close this point as well. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Friday, March 02, 2012 1:09 AM > > > To: Rajiv Asati (rajiva) > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Rajiv, > > > See some follow-up inline. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > > Sent: Wednesday, February 29, 2012 10:28 PM > > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > > > > > Thanks for the review of the document and the feedback. It is never > > too late. > > > :) Sorry about the delay in getting back to you. > > > > > > Please see inline, > > > > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > Yes, they were discussed in the past and closed. > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > No. > > > > > > While it is a common practice to assign a host route to the loopback > > interface, > > > and it is a common practice to use loopback interface as the > next-hop, > > we > > > must not assume the common practice to be the norm for the protocol. > > In > > > fact, there is NO technical argument against using the non-host > route > > on a > > > loopback interface. > > > > > > In fact, almost every implementation allows the next-hop to be a > > non-host > > > route, and I am aware of at least one implementation that allows LDP > > to > > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that > if > > hello adj > > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > > forwarding on that interface. So, if IPv6 hello adj failed, then > stop > > the IPv6 > > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > > blindly > > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > > > // > > > when it receives a Hello that matches the adjacency. If the > timer > > > expires without receipt of a matching Hello from the peer, LDP > > > concludes that the peer no longer wishes to label switch using > that > > > label space for that link (or target, in the case of Targeted > > Hellos) > > > or that the peer has failed. The LSR then deletes the Hello // > > > > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > > > I agree. It doesn't have anything to do with the address family, but > > it > > > becomes restrictive when having to accommodate transport of two > > different > > > address families (IPv4 and IPv6). Pls see more details on this later > > on. > > > > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > That's not correct (and the implementation is in violation of > > RFC5036). > > > > > > We had good discussion on this early on. In fact, we had an editor's > > note on > > > this in initial versions of this document to solicit discussion on > > that. > > > > > > The last para of section 2.5.2, as stated, would result in a > > particular IP address > > > (1.1.1.1, say) being encoded in the transport address in both > > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > > (which is > > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > > from > > > carrying IPv6 transport address (or IPv4 hello from carrying > > > IPv4 transport address). It would not make sense. > > > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > > address > > > and vice versa. It wouldn't make sense and would be incorrect. > > > > > > That's why the change was needed. > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. It becomes an issue of association of multiple > > Hello > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > We thought so too, but we uncovered various corner cases in which > this > > > becomes problematic, not to mention that the indeterminism it would > > bring > > > into the picture. The easiest was to maintain hello adj per > > address-family per > > > peer. > > > > > > For ex, consider three LDP enabled interfaces between R1 and R2, > where > > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > > maintain only > > > single adj, then they would have hello adj of one transport (v6, > say) > > on dual- > > > stack interfaces, and another transport (v4, > > > say) on 3rd interface. > > > > > > Hello adj is tightly coupled with the functional LDP peering. If > (the > > > last) hello adj is lost, then LDP peering must be brought down. > > > Additionally, if hello adj is gone from an interface, then LDP > should > > prohibit > > > MPLS forwarding from using that interface. > > > > > > Another way to think about it is - if IPv4 stops functioning on an > > interface, but > > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > > penalized. > > > And vice versa. > > > > > > Having separate hello adj maintenance is much cleaner/simpler and > > provides > > > deterministic behavior. > > > > > > Nonetheless, an implementation could choose to optimize, if needed, > to > > > keep both address-family related info in a single adjacency > structure, > > but this > > > is all implementation specific. :) > > > > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > Good point, but this is a different problem. It is not about the > > sequence > > > (which was ok if IPv4 hellow as carrying two IPv4 transport > > addresses). > > > > > > The problem is that allowing IPv4 based "discovery" to suggest an > IPv6 > > > transport address is fundamentally a wrong approach, IMO. How would > > IPv4 > > > know that IPv6 transport is even functional (and vice versa). IPv4 > > based > > > discovery should suggest IPv4 transport, and IPv6 based discovery > > should > > > suggest IPv6 transport. > > > > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. BGP allows the exchage of IPv4 prefixes over an > IPv6 > > > connection and vice-versa. There is no relationship whatsoever > between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > We need the address-family awareness in peer hello adjacency/s, > > whether it > > > is a kept in a single adj structure or not. > > > > > > Loosing the AFI awareness leads up the other problems that I > mentioned > > > earlier. > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > It is MAY. :) > > > It was changed to MAY based on the exhaustive discussion on mailing > > list in > > > 2011 for us to move forward. > > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > different protocol. > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > We initially thought so too, until we discovered the following very > > explicitly in > > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > > > // > > > Section 3.5.5.1 - > > > If an LSR does not support the Address Family specified in the > Address > > List > > > TLV, it SHOULD send an Unsupported Address Family Notification to > its > > LDP > > > signaling an error and abort processing the message. > > > > > > Section 3.4.1.1 - > > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > > Address > > > Family it does not support, it SHOULD stop decoding the FEC TLV, > abort > > > processing the message containing the TLV, and send an "Unsupported > > > Address Family" Notification message to its LDP peer signaling an > > error. > > > // > > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > Because it is native in IPv6 to allow for link-local addresses that > > IPv4 never > > > allowed. > > > So, what was an anomaly with IPv4 is now a standard behavior with > > IPv6, > > > hence, that verbiage. > > > > > > > > > > > 10. Section 9 - LDP TTL Security > > > > > " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > We posed the Q about GTSM being the default or not during IETF 80, > and > > > there were 10-yes and 0-no (mostly from operators) Pls see the > > minutes, > > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > > > Cheers, > > > Rajiv > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Aissaoui, Mustapha (Mustapha) > > > > Sent: Monday, February 06, 2012 3:21 PM > > > > To: Shane Amante > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Shane, > > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > > LDP > > > session > > > > from a peer which is identified by the LDP identifier tuple > {LSR-id, > > > label-space- > > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > > different label > > > > spaces, then they must use two different Hello adjacencies and LDP > > > sessions for > > > > that. Also, if an implementation supports virtualization of LDP, > > then > > > a different > > > > LDP identifier altogether can be used to establish a separate LDP > > > session. Other > > > > than that, there is no relation between the type of adjacency and > > the > > > FEC which > > > > are carried. For example, the same LDP Hello Adjacency and LDP > > session > > > are > > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > > between > > > two > > > > directly connected peers. > > > > > > > > As far as I know BGP is not very different. It offers the ability > to > > > carry IPv4 NLRI > > > > over a IPv6 session and vice versa. > > > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > > IPv4 > > > on an IPv4 > > > > session between two LSRs, then we should consider extending RFC > > 5036 > > > to > > > > allow for two different LSR-id values sharing the same global > label > > > space. This > > > > way, we can have separate Hello adjacency and LDP session and it > is > > up > > > to the > > > > user to assign which FEC type is allowed on which LDP session. > This > > is > > > a new > > > > work item but in my view much cleaner and backward compatible with > > RFC > > > > 5036 than to try to tie the address family to the type of Hello > > > adjacency. > > > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > > Hello > > > > adjacency but a single shared LDP session. It is not exactly what > > you > > > are asking > > > > for. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > -----Original Message----- > > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > > Sent: Friday, February 03, 2012 11:32 PM > > > > To: Aissaoui, Mustapha (Mustapha) > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Mustapha, > > > > > > > > I am not an author, but I do want to provide some operational > input > > on > > > some of > > > > your comments. Specifically, I get the sense from several of your > > > comments -- > > > > actually, moreso from #3 -- that you are opposed to maintaining > > > separate LDP > > > > Hello and/or Session Adjacencies: 1 for each address family. (If > my > > > impression > > > > is incorrect I apologize). > > > > > > > > I actually *do* want to have separate LDP Hello and Session > > > adjacencies: one > > > > per address family, at least at this point in time. I'm concerned > > > about > > > > [operational] issues that may develop in, for example, v6 > affecting > > > the > > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > > one > > > more > > > > concrete example, 6man/v6ops are only right now working on > improving > > > the > > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > > areas where > > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > > problems in v6 > > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > > FWIW, there has > > > > already been a precedent here wrt BGP where there it maintains > > > separate > > > > neighbors/sessions for each address family, so why aren't we doing > > the > > > same > > > > thing for LDP? > > > > > > > > Ultimately, having separate sessions over-the-wire is much more > > > intuitive to > > > > operators in lots of cases where they may expect that a > > configuration > > > change > > > > or bugs they /think/ are only going to affect one address family, > > > really do only > > > > affect one address family. Besides, LDP Hello & Sessions timers, > > when > > > set to > > > > default, are extremely relaxed (order of several seconds), so the > > > burden on > > > > implementations to maintain separate sessions should be miniscule. > > > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > > over the > > > > wire to avoid "fate sharing". Only when an operator chooses to > > > explicitly > > > > configure their device to have hellos and sessions share fate > should > > > the device > > > > do so. > > > > > > > > Just my $0.02, > > > > > > > > -shane > > > > > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > > Dear authors, > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > > > > > > > > > > 10. Section 9 - LDP TTL Security > > > > > " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From wwwrun@rfc-editor.org Sun Apr 1 23:23:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4211E80B2 for ; Sun, 1 Apr 2012 23:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzcv5Q9ZS5q1 for ; Sun, 1 Apr 2012 23:23:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2061711E8073 for ; Sun, 1 Apr 2012 23:23:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0ED91B1E002; Sun, 1 Apr 2012 23:23:31 -0700 (PDT) To: erosen@cisco.com, arun@force10networks.com, rcallon@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20120402062331.0ED91B1E002@rfc-editor.org> Date: Sun, 1 Apr 2012 23:23:31 -0700 (PDT) Cc: mpls@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3031 (3171) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 06:23:34 -0000 The following errata report has been submitted for RFC3031, "Multiprotocol Label Switching Architecture". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3031&eid=3171 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.20 Original Text ------------- Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (c) being the "finest granularity". Corrected Text -------------- Given a set of FECs which are "aggregatable" into a single FEC, it is possible to (a) aggregate them into a single FEC, (b) aggregate them into a set of FECs, or (c) not aggregate them at all. Thus we can speak of the "granularity" of aggregation, with (a) being the "coarsest granularity", and (b) being the "finest granularity". Notes ----- In the case of (c) the aggregation is not used, so there is no granularity. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3031 (draft-ietf-mpls-arch-06) -------------------------------------- Title : Multiprotocol Label Switching Architecture Publication Date : January 2001 Author(s) : E. Rosen, A. Viswanathan, R. Callon Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From ice@cisco.com Mon Apr 2 00:34:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5757E21F86DB for ; Mon, 2 Apr 2012 00:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iGXnotoxwbx for ; Mon, 2 Apr 2012 00:34:20 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E19D321F86D9 for ; Mon, 2 Apr 2012 00:34:19 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q327YILw016789 for ; Mon, 2 Apr 2012 09:34:18 +0200 (CEST) Received: from ams-iwijnand-87111.cisco.com (ams-iwijnand-87111.cisco.com [10.55.191.156]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q327YIGF012888; Mon, 2 Apr 2012 09:34:18 +0200 (CEST) From: IJsbrand Wijnands Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 09:34:17 +0200 Message-Id: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> To: "Emily Chen(Ying)" , Quintin Zhao Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: mpls@ietf.org Subject: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 07:34:21 -0000 Dear Emily & Quintin, The solution in this draft requires a mLDP router upstream of the = non-mLDP router to do the packet forwarding and replication. The = receiver interest is signaled to the upstream router via tLDP sessions. = The upstream router will end up with the number of tLDP session to all = the of the receivers downstream of the non-mLDP router, and will have to = replicate the multicast packets over P2P LSPs to them.je This has exactly the same tLDP scale considerations as discussed in the = context of draft-wijnands-mpls-mldp-node-protection-00, yet for mLDP = node protection it seems to be a concern for you? Thx, Ice. BTW, we already have had a fair bit of discussion on the list Oct 2011 = regarding the other concerns for this draft.= From eosborne@cisco.com Mon Apr 2 02:56:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F5621F86DC for ; Mon, 2 Apr 2012 02:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.51 X-Spam-Level: X-Spam-Status: No, score=-8.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leOmXtTHzgos for ; Mon, 2 Apr 2012 02:56:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D713521F86DB for ; Mon, 2 Apr 2012 02:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=10345; q=dns/txt; s=iport; t=1333360589; x=1334570189; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zunMcdow4gu3OxwwK6d2d9W7sMD3A2JLpforX6Lw8hI=; b=TW1fNPAjpBerF2DmPjZmumwy+47mItIdcz9FsiOYg+2ki7GkOSBkMhkc d0y72cOS84cQ8CEO01rDOxnlY0D5v0U8+ffVfsIsyLE6472A8t/AZcP4V r8KqJfqv+uIXJqLcEwUCQ3JqhnGoNsjdO2IzorUFEAh3UqiAGzSbENaOi 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA13eU+tJV2d/2dsb2JhbABDuRKBB4IJAQEBBAEBAQ8BHQo0FwQCAQgRBAEBCwYXAQYBJh8JCAIEARIIGodnC599llUEixqFH2MEiFibUIFogwWBNgIV X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="71298932" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 02 Apr 2012 09:56:29 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q329uT3e028100; Mon, 2 Apr 2012 09:56:29 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 04:56:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 04:56:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpA References: From: "Eric Osborne (eosborne)" To: "Maarten vissers" , "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 02 Apr 2012 09:56:29.0034 (UTC) FILETIME=[DFE9B4A0:01CD10B6] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:56:31 -0000 Hi Maarten- =20 How does a node know that two requests are of equal priority? Is this somehow configured a priori on the MSP endpoints? eric > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Thursday, March 29, 2012 3:06 PM > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Below is a copy of the equal priority text in G.873.1 (OTN linear > protection): >=20 > 8.10 Equal priority requests > In general, once a switch has been completed due to a request, it will not > be overridden by another request of the same priority (first come, first > served behaviour). When equal priority requests occur simultaneously, the > conflict is resolved in favour of the request with the lowest entity > number. In bidirectional switching, a request received over the APS > channel with a lower entity number will always override an identical > priority local request with a higher entity number. Equal priority > requests for the same entity number from both sides of a bidirectional > protection group are both considered valid, and equivalent to a received > "RR" from a near-end processing standpoint. >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Maarten vissers > Sent: donderdag 29 maart 2012 14:54 > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 >=20 > 1:n protection in a transport network at the path layer is not a very > common protection switching application. This is due to the fact that 1:n > protection requires n+1 diverse routed paths. How many of those diverse > routed paths will be available in typical transport networks? Not many... > very often two diverse routed paths is all you can get... and this is only > truly guaranteed over time if the network domain is organized as separate > A and a B networks. Otherwise maintenance on the network may result in > temporary rerouting of virtual links, resulting in routing W and P > connections over the same fiber, node or duct. >=20 > With n>2, separate networks can not be used and one has to find n+1 > diverse routed paths through the network and guarantee that neither > maintenance activities, nor network upgrades result in rerouting of the > virtual links so that W and P connections pass through the same fiber, > node or duct. >=20 > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > protection (1:7 and 1:11 systems, in early 90's) and for SDH line card > protection (end of 90's). >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Osborne (eosborne) > Sent: donderdag 29 maart 2012 14:31 > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 >=20 > I still go back to my point that since only one W can ever use P, there > really is no such thing as 'equal priority'. We must have a priority > scheme, whether it is the channel number in Fpath or whether it's some > other mechanism, so that we know that Wi always beats Wj no matter what > order the events occur in. >=20 > We had initially discussed leaving the exact priority scheme to the > protection endpoints, but I see now that that may not work well across > vendors. >=20 > I think we have a few choices: >=20 > 1) some sort of explicit priority field > 2) define priority as the FPath value, lower is better (as Maarten > points out, this is the current practice in SDH). >=20 > Either one of these have costs to them. >=20 > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in > locking mode means nobody is protected until both ends converge. This > also makes things (potentially) very dynamic which is, I think, not what > we want in a protocol that has to converge in real time. >=20 > Doing #2 means that if I have W1...W5 already provisioned and I want to > add W3.1, I need to reprovision W4 and W5, which may be disruptive. How > often does this sort of thing happen in transport networks? Is it a > real problem? >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 2:21 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Eric, > > I agree with your logic and that current document handles scenario you > > present (prioties of simulteneously failed paths are different) well. > But > > I still am concerned with case when priorities of Wi and Wj are equal. > If > > you think that it might present a problem, then I see two possible > ways to > > address: > > - disallow multiple LSPs being assigned equal priority (not the best > way); > > - define tiebreaking rule(s). > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 5:11 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Let me rewrite the messages a little bit in your example. Rather than > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs > in > > question. And let's also say that the priority of Wi > Wj, just as > you > > have done. > > > > I also note that setting Path=3D=3D0 means you're using locking = mode. > This is > > certainly a valid case, I just want to confirm that it's your > intention? > > > > at t0, no failure. > > > > at t1, > > LER-A sends SF(Wi,0) to LER-Z > > AND > > LER-Z sends SF(Wj,0) to LER-Z > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > > decided that Wi needs the protect channel. > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, > > shortly after t2. > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > unidirectional locking preemption case, as in section 3.3.3.2 of the > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > In this way, both LER-A and LER-Z converge on protecting Wi. Since it > is > > locking, no transmission of packets takes place since neither side had > > ACKd the other side's SF. > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 1:51 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Eric, > > > Below is scenario that in my view would benefit from a tiebreaking > > rule. > > > Would appreciate your consideration and feedback whether this is > > realistic > > > and not breaking PSC: > > > - Assume that LSP P is not being used or used by working path of > > priority > > > N; > > > - LER-A detects failure of working path Wi of priority M, where M > > N, > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > - almost simulteneously, at least before it receives SF from LER-A, > > LER-Z > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > listing > > Wj > > > as Fpath; > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > > Priority(Wj) > > > would not change to protecting Wi path; > > > - LER-A receives SF(1,0) from LER-Z and for the same reason would > keep > > Wi > > > as path to protect. > > > Is that sequence, scenario correct? Would LER-A and LER-Z converge > on > > > selecting one path they'd protect? > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 4:38 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > priority". > > > > There must be a tiebreaker that can handle all possible conflicts, > > no > > > > matter what order or how many failures. Once there is a > > deterministic > > > > mechanism for all cases, it means that all LSPs are of different > > > priority. > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > failure > > > of > > > > two working paths of equal priority. Otherwise, equal priority > would > > > not > > > > preempt one that is already is using the protection path, i.e. > FIFO > > > will > > > > fully work in this case. > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. In > 1:n > > we'd > > > always made the assumption that, in a given protection domain, only > a > > > single W can be protected at a time. To do otherwise (say, W1 and > W2 > > > using P) is not possible using PSC signaling since we can only > > indicate a > > > single LSP in the FPath field. > > > > > > Nothing precludes multiple protection domains from using the same > > > underlying link and/or same endpoints, but that's a network design > > > consideration. > > > > > > > > > > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From maarten.vissers@huawei.com Mon Apr 2 03:10:11 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA79C21F88DB for ; Mon, 2 Apr 2012 03:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7roMo4pPoi5 for ; Mon, 2 Apr 2012 03:10:06 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DE69A21F887A for ; Mon, 2 Apr 2012 03:10:05 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW75849; Mon, 02 Apr 2012 06:10:04 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 03:06:47 -0700 Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 03:06:48 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.01.0323.003; Mon, 2 Apr 2012 11:06:44 +0100 From: Maarten vissers To: "Eric Osborne (eosborne)" , Gregory Mirsky , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEA= Date: Mon, 2 Apr 2012 10:06:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.112.103] Content-Type: multipart/alternative; boundary="_000_D62E6669B3621943B7632961308F8F9E0DD7D3DAlhreml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:10:11 -0000 --_000_D62E6669B3621943B7632961308F8F9E0DD7D3DAlhreml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eric, The standard specifies the priority order of requests. E.g. in G.873.1 (OTN= linear protection, http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-= REC-G.873.1-201107-I!!PDF-E&type=3Ditems) the following specification is in= cluded: 8.3 Request type The request types that may be reflected in the APS bytes are the "standard"= types traditionally supported by protection switching for SONET and SDH. T= hese requests reflect the highest priority condition, command, or state (se= e Tables 2 and 3). In the case of unidirectional switching, this is the hig= hest priority value determined from the near end only. In bidirectional swi= tching, the local request will be indicated only in the case where it is as= high or higher than any request received from the far end over the APS cha= nnel. In bidirectional switching, when the far end request has the highest = priority, the near end will signal Reverse Request. Table 2/G.873.1 - Request/state priorities with APS protocol Request/state Priority Lockout for Protection (LoP) 1 (highest) Signal Fail (SF) - protection 2 (see 8.9) Forced Switch (FS) 3 Signal Fail (SF) - working 4 Signal Degrade (SD) 5 Manual Switch (MS) 6 Wait-to-Restore (WTR) 7 Exercise (EXER) 8 Reverse Request (RR) 9 Do Not Revert (DNR) 10 No Request (NR) 11 (lowest) Table 3/G.873.1 - Request/state priorities without APS protocol Request/state Priority Lockout for Protection (LoP) 1 (highest) Forced Switch (FS) 2 Signal Fail (SF) 3 Signal Degrade (SD) 4 Manual Switch (MS) 5 Wait-to-Restore (WTR) 6 Do Not Revert (DNR) 7 No Request (NR) 8 (lowest) Regards, Maarten -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] Sent: maandag 2 april 2012 11:56 To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingart= en; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 Hi Maarten- How does a node know that two requests are of equal priority? Is this somehow configured a priori on the MSP endpoints? eric > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Thursday, March 29, 2012 3:06 PM > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > Below is a copy of the equal priority text in G.873.1 (OTN linear > protection): > > 8.10 Equal priority requests > In general, once a switch has been completed due to a request, it will not > be overridden by another request of the same priority (first come, first > served behaviour). When equal priority requests occur simultaneously, the > conflict is resolved in favour of the request with the lowest entity > number. In bidirectional switching, a request received over the APS > channel with a lower entity number will always override an identical > priority local request with a higher entity number. Equal priority > requests for the same entity number from both sides of a bidirectional > protection group are both considered valid, and equivalent to a received > "RR" from a near-end processing standpoint. > > Regards, > Maarten > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Maarten vissers > Sent: donderdag 29 maart 2012 14:54 > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > 1:n protection in a transport network at the path layer is not a very > common protection switching application. This is due to the fact that 1:n > protection requires n+1 diverse routed paths. How many of those diverse > routed paths will be available in typical transport networks? Not many... > very often two diverse routed paths is all you can get... and this is only > truly guaranteed over time if the network domain is organized as separate > A and a B networks. Otherwise maintenance on the network may result in > temporary rerouting of virtual links, resulting in routing W and P > connections over the same fiber, node or duct. > > With n>2, separate networks can not be used and one has to find n+1 > diverse routed paths through the network and guarantee that neither > maintenance activities, nor network upgrades result in rerouting of the > virtual links so that W and P connections pass through the same fiber, > node or duct. > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > protection (1:7 and 1:11 systems, in early 90's) and for SDH line card > protection (end of 90's). > > Regards, > Maarten > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Osborne (eosborne) > Sent: donderdag 29 maart 2012 14:31 > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > I still go back to my point that since only one W can ever use P, there > really is no such thing as 'equal priority'. We must have a priority > scheme, whether it is the channel number in Fpath or whether it's some > other mechanism, so that we know that Wi always beats Wj no matter what > order the events occur in. > > We had initially discussed leaving the exact priority scheme to the > protection endpoints, but I see now that that may not work well across > vendors. > > I think we have a few choices: > > 1) some sort of explicit priority field > 2) define priority as the FPath value, lower is better (as Maarten > points out, this is the current practice in SDH). > > Either one of these have costs to them. > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in > locking mode means nobody is protected until both ends converge. This > also makes things (potentially) very dynamic which is, I think, not what > we want in a protocol that has to converge in real time. > > Doing #2 means that if I have W1...W5 already provisioned and I want to > add W3.1, I need to reprovision W4 and W5, which may be disruptive. How > often does this sort of thing happen in transport networks? Is it a > real problem? > > > > > eric > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, March 29, 2012 2:21 PM > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Eric, > > I agree with your logic and that current document handles scenario you > > present (prioties of simulteneously failed paths are different) well. > But > > I still am concerned with case when priorities of Wi and Wj are equal. > If > > you think that it might present a problem, then I see two possible > ways to > > address: > > - disallow multiple LSPs being assigned equal priority (not the best > way); > > - define tiebreaking rule(s). > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: Thursday, March 29, 2012 5:11 AM > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Let me rewrite the messages a little bit in your example. Rather than > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the LSPs > in > > question. And let's also say that the priority of Wi > Wj, just as > you > > have done. > > > > I also note that setting Path=3D=3D0 means you're using locking mode. > This is > > certainly a valid case, I just want to confirm that it's your > intention? > > > > at t0, no failure. > > > > at t1, > > LER-A sends SF(Wi,0) to LER-Z > > AND > > LER-Z sends SF(Wj,0) to LER-Z > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > > decided that Wi needs the protect channel. > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at t3, > > shortly after t2. > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > unidirectional locking preemption case, as in section 3.3.3.2 of the > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > In this way, both LER-A and LER-Z converge on protecting Wi. Since it > is > > locking, no transmission of packets takes place since neither side had > > ACKd the other side's SF. > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 1:51 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Eric, > > > Below is scenario that in my view would benefit from a tiebreaking > > rule. > > > Would appreciate your consideration and feedback whether this is > > realistic > > > and not breaking PSC: > > > - Assume that LSP P is not being used or used by working path of > > priority > > > N; > > > - LER-A detects failure of working path Wi of priority M, where M > > N, > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > - almost simulteneously, at least before it receives SF from LER-A, > > LER-Z > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > listing > > Wj > > > as Fpath; > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > > Priority(Wj) > > > would not change to protecting Wi path; > > > - LER-A receives SF(1,0) from LER-Z and for the same reason would > keep > > Wi > > > as path to protect. > > > Is that sequence, scenario correct? Would LER-A and LER-Z converge > on > > > selecting one path they'd protect? > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 4:38 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > priority". > > > > There must be a tiebreaker that can handle all possible conflicts, > > no > > > > matter what order or how many failures. Once there is a > > deterministic > > > > mechanism for all cases, it means that all LSPs are of different > > > priority. > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > failure > > > of > > > > two working paths of equal priority. Otherwise, equal priority > would > > > not > > > > preempt one that is already is using the protection path, i.e. > FIFO > > > will > > > > fully work in this case. > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. In > 1:n > > we'd > > > always made the assumption that, in a given protection domain, only > a > > > single W can be protected at a time. To do otherwise (say, W1 and > W2 > > > using P) is not possible using PSC signaling since we can only > > indicate a > > > single LSP in the FPath field. > > > > > > Nothing precludes multiple protection domains from using the same > > > underlying link and/or same endpoints, but that's a network design > > > consideration. > > > > > > > > > > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --_000_D62E6669B3621943B7632961308F8F9E0DD7D3DAlhreml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Eric,
 
The standard specifies the priority order of requests. E.g. in G.873.1= (OTN linear protection, http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-R= EC-G.873.1-201107-I!!PDF-E&type=3Ditems) the following specification is included:
 
=
8= .3     Request type
The = request types that may be reflected in the APS bytes are the "standard= " types traditionally supported by protection switching for SONET and = SDH. These requests reflect the highest priority condition, command, or state (see Tables 2 and 3). In the case of unidirect= ional switching, this is the highest priority value determined from the nea= r end only. In bidirectional switching, the local request will be indicated= only in the case where it is as high or higher than any request received from the far end over the APS chan= nel. In bidirectional switching, when the far end request has the highest p= riority, the near end will signal Reverse Request.
<= b>Table 2/G.873.1 – Request/state priorities with APS protocol
Request/state Priority
Lockout for Protection (LoP)= 1 (highest)
Signal Fail (SF) – pro= tection 2 (see 8.9)
Forced Switch (FS) 3
Signal Fail (SF) – wor= king 4
Signal Degrade (SD) 5
Manual Switch (MS) 6
Wait-to-Restore (WTR)= 7
Exercise (EXER) 8
Reverse Request (RR)<= /font> 9
Do Not Revert (DNR) 10
No Request (NR) 11 (lowest)
<= b>Table 3/G.873.1 – Request/state priorities without APS protocol=
Request/state Priority
Lockout for Protection (LoP)= 1 (highest)
Forced Switch (FS) 2
Signal Fail (SF) 3
Signal Degrade (SD) 4
Manual Switch (MS) 5
Wait-to-Restore (WTR)= 6
Do Not Revert (DNR) 7
No Request (NR) 8 (lowest)
 
 
 
Regards,
Maarten
 
 
-----Original Message-----
From: Eric Osborne (eosborne) [mailto= :eosborne@cisco.com]
Sent: maandag 2 april 2012 11:56
To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingart= en; mpls@ietf.org
Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
 
Hi Maarten-
 
How does a node know that two requests are of equal priority?  I= s this
somehow configured a priori on the MSP endpoints?
 
 
 
 
eric
 
 
> -----Original Message-----
> From: Maarten vissers [mailto:maarten.vissers@huawei.com]
> Sent: Thursday, March 29, 2012 3:06 PM
> To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky;
> zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org
> Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> Below is a copy of the equal priority text in G.873.1 (OTN linear=
> protection):
>
> 8.10  Equal priority requests
> In general, once a switch has been completed due to a request, it= will
not
> be overridden by another request of the same priority (first come= ,
first
> served behaviour). When equal priority requests occur simultaneou= sly,
the
> conflict is resolved in favour of the request with the lowest ent= ity
> number. In bidirectional switching, a request received over the A= PS
> channel with a lower entity number will always override an identi= cal
> priority local request with a higher entity number. Equal priorit= y
> requests for the same entity number from both sides of a bidirect= ional
> protection group are both considered valid, and equivalent to a
received
> "RR" from a near-end processing standpoint.
>
> Regards,
> Maarten
>
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
Of
> Maarten vissers
> Sent: donderdag 29 maart 2012 14:54
> To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.c= n;
Yaacov
> Weingarten; mpls@ietf.org
> Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01=
>
> 1:n protection in a transport network at the path layer is not a = very
> common protection switching application. This is due to the fact = that
1:n
> protection requires n+1 diverse routed paths. How many of tho= se
diverse
> routed paths will be available in typical transport networks? Not=
many...
> very often two diverse routed paths is all you can get... and thi= s is
only
> truly guaranteed over time if the network domain is organized as<= /div>
separate
> A and a B networks. Otherwise maintenance on the network may resu= lt in
> temporary rerouting of virtual links, resulting in routing W and = P
> connections over the same fiber, node or duct.
>
> With n>2, separate networks can not be used and one has to fin= d n+1
> diverse routed paths through the network and guarantee that neith= er
> maintenance activities, nor network upgrades result in rerouting = of
the
> virtual links so that W and P connections pass through the same f= iber,
> node or duct.
>
> 1:n protection has been used in SDH/SONET for SDH/SONET regenerat= or
> protection (1:7 and 1:11 systems, in early 90's) and for SDH line= card
> protection (end of 90's).
>
> Regards,
> Maarten
>
> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf
Of
> Eric Osborne (eosborne)
> Sent: donderdag 29 maart 2012 14:31
> To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;
> mpls@ietf.org
> Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01=
>
> I still go back to my point that since only one W can ever use P,=
there
> really is no such thing as 'equal priority'.  We must have a= priority
> scheme, whether it is the channel number in Fpath or whether it's= some
> other mechanism, so that we know that Wi always beats Wj no matte= r
what
> order the events occur in.
>
> We had initially discussed leaving the exact priority scheme to t= he
> protection endpoints, but I see now that that may not work well a= cross
> vendors.
>
> I think we have a few choices:
>
> 1) some sort of explicit priority field
> 2) define priority as the FPath value, lower is better (as Maarte= n
> points out, this is the current practice in SDH).
>
> Either one of these have costs to them.
>
> Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 = has
> prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, a= nd in
> locking mode means nobody is protected until both ends converge.&= nbsp; This
> also makes things (potentially) very dynamic which is, I think, n= ot
what
> we want in a protocol that has to converge in real time.
>
> Doing #2 means that if I have W1...W5 already provisioned and I w= ant
to
> add W3.1, I need to reprovision W4 and W5, which may be disruptiv= e.
How
> often does this sort of thing happen in transport networks? = Is it a
> real problem?
>
>
>
>
> eric
>
> > -----Original Message-----
> > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> > Sent: Thursday, March 29, 2012 2:21 PM
> > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov
Weingarten;
> > mpls@ietf.org
> > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> >
> > Hi Eric,
> > I agree with your logic and that current document handles sc= enario
you
> > present (prioties of simulteneously failed paths are differe= nt)
well.
> But
> > I still am concerned with case when priorities of Wi and Wj = are
equal.
> If
> > you think that it might present a problem, then I see two po= ssible
> ways to
> > address:
> > - disallow multiple LSPs being assigned equal priority (not = the best
> way);
> > - define tiebreaking rule(s).
> >
> >      Regards,
> >          &= nbsp;   Greg
> >
> > -----Original Message-----
> > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > Sent: Thursday, March 29, 2012 5:11 AM
> > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten= ;
> > mpls@ietf.org
> > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> > Let me rewrite the messages a little bit in your example.&nb= sp; Rather
than
> > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are= the
LSPs
> in
> > question.  And let's also say that the priority of Wi &= gt; Wj, just as
> you
> > have done.
> >
> > I also note that setting Path=3D=3D0 means you're using lock= ing mode.
> This is
> > certainly a valid case, I just want to confirm that it's you= r
> intention?
> >
> > at t0, no failure.
> >
> > at t1,
> >   LER-A sends SF(Wi,0) to LER-Z
> >     AND
> >   LER-Z sends SF(Wj,0) to LER-Z
> >
> > at t2, LER-A receives SF(Wj,0).  It ignores it, since i= t has already
> > decided that Wi needs the protect channel.
> >
> > LER-Z also receives SF(Wi,0).  This is either exactly a= t t2, or at
t3,
> > shortly after t2.
> >
> > LER-Z knows a priori that Wi > Wj, so LER-Z treats this a= s a
> > unidirectional locking preemption case, as in section 3.3.3.= 2 of the
> > draft.  LER-Z responds to the SF(Wi,0) with NR(Wi,0).&n= bsp; This is what
> > 3.3.3.2 describes as LER-A's behavior at t1.
> >
> > In this way, both LER-A and LER-Z converge on protecting Wi.=   Since
it
> is
> > locking, no transmission of packets takes place since neithe= r side
had
> > ACKd the other side's SF.
> >
> > Does that reflect your question, and does it answer it?
> >
> >
> >
> >
> >
> > eric
> >
> > > -----Original Message-----
> > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> > > Sent: Thursday, March 29, 2012 1:51 PM
> > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaa= cov
> Weingarten;
> > > mpls@ietf.org
> > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection= -01
> > >
> > > Hi Eric,
> > > Below is scenario that in my view would benefit from a = tiebreaking
> > rule.
> > > Would appreciate your consideration and feedback whethe= r this is
> > realistic
> > > and not breaking PSC:
> > > - Assume that LSP P is not being used or used by workin= g path of
> > priority
> > > N;
> > > - LER-A detects failure of working path Wi of priority = M, where M
>
> N,
> > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath;
> > > - almost simulteneously, at least before it receives SF= from
LER-A,
> > LER-Z
> > > detects failure of Wj that has priority M. LER-Z sends = SF(1,0)
> listing
> > Wj
> > > as Fpath;
> > > - LER-Z receives SF(1,0) from LER-A and since Priority(= Wi) =3D=3D
> > Priority(Wj)
> > > would not change to protecting Wi path;
> > > - LER-A receives SF(1,0) from LER-Z and for the same re= ason would
> keep
> > Wi
> > > as path to protect.
> > > Is that sequence, scenario correct? Would LER-A and LER= -Z converge
> on
> > > selecting one path they'd protect?
> > >
> > >    Regards,
> > >         &n= bsp;  Greg
> > >
> > > -----Original Message-----
> > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > > Sent: Thursday, March 29, 2012 4:38 AM
> > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weing= arten;
> > > mpls@ietf.org
> > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection= -01
> > >
> > >
> > > > EO#  I would argue that one should not have L= SPs of the "same
> > > priority".
> > > > There must be a tiebreaker that can handle all pos= sible
conflicts,
> > no
> > > > matter what order or how many failures.  Once= there is a
> > deterministic
> > > > mechanism for all cases, it means that all LSPs ar= e of different
> > > priority.
> > > >
> > > > GIM>> Tiebreaking would be used only in case= of simulteneous
> failure
> > > of
> > > > two working paths of equal priority. Otherwise, eq= ual priority
> would
> > > not
> > > > preempt one that is already is using the protectio= n path, i.e.
> FIFO
> > > will
> > > > fully work in this case.
> > >
> > >
> > > I think the behavior you describe is more about SMP tha= n 1:n.  In
> 1:n
> > we'd
> > > always made the assumption that, in a given protection = domain,
only
> a
> > > single W can be protected at a time.  To do otherw= ise (say, W1 and
> W2
> > > using P) is not possible using PSC signaling since we c= an only
> > indicate a
> > > single LSP in the FPath field.
> > >
> > > Nothing precludes multiple protection domains from usin= g the same
> > > underlying link and/or same endpoints, but that's a net= work design
> > > consideration.
> > >
> > >
> > >
> > >
> > > eric
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
 
--_000_D62E6669B3621943B7632961308F8F9E0DD7D3DAlhreml509mbx_-- From eosborne@cisco.com Mon Apr 2 03:49:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6145321F896E for ; Mon, 2 Apr 2012 03:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.88 X-Spam-Level: X-Spam-Status: No, score=-7.88 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2+XpfARzfkM for ; Mon, 2 Apr 2012 03:49:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A69FE21F896D for ; Mon, 2 Apr 2012 03:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=15005; q=dns/txt; s=iport; t=1333363791; x=1334573391; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=nfctQbG4wj/G4u/DBf2CD5f+TpCZsCV6g/3NDrZHEp4=; b=BNzMqB5y2+7DLQO15JiTq2wm/U8UwfQMSD8wQB70a1YjHU0RGOk2xVM9 tSYfvqMCZHLDZEhfnFcqE81qbYhd1YCgyZhsgSBlAXW57D1qSqDK2g0Cm VzNX7kczyJPP8DbKg1Mxx+klAB8E8HIy1AyUcVuiwsmxFYwCVMr/SoMKW 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHaDeU+tJXG9/2dsb2JhbABDuRuBB4IJAQEBBAEBAQ8BHT4XBAIBBgIRAwEBAQsGFwEGASAGHwkIAgQBEggah2cLn3GWYooWgQSFH2MEiFiOGooYCoMUgWiDBYE2AgYP X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="71313668" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 02 Apr 2012 10:49:51 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q32Anoeo022883; Mon, 2 Apr 2012 10:49:50 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 05:49:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 05:49:58 -0500 Message-ID: In-Reply-To: <6AB52EA5AA7B4A4F81C6DC3AFF6D7FCA@etri.info> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAP3CaQAAtpRQ References: <6AB52EA5AA7B4A4F81C6DC3AFF6D7FCA@etri.info> From: "Eric Osborne (eosborne)" To: =?ks_c_5601-1987?B?t/nBpLW/?= , "Maarten vissers" , "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 02 Apr 2012 10:49:50.0935 (UTC) FILETIME=[54650670:01CD10BE] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:49:53 -0000 Sure, but what we're trying to address here is the requirement for 1:n. As I understand (1:1)^n it's just a set of 1:1 protection sessions = provisioned by some central box with knowledge of the potential = conflicts between other boxes. This isn't something we need new state = machines or packet formats for, and thus doesn't seem like something we = need to standardize. FRR, although it is different from any of the = transport-style protection methods, has been provisioned like this for = years. eric > -----Original Message----- > From: =B7=F9=C1=A4=B5=BF [mailto:ryoo@etri.re.kr] > Sent: Monday, April 02, 2012 6:28 AM > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > Subject: RE: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi, >=20 > For packet networks, if one ever wants to have n working connections = be > protected by 1 protection connection, > (1:1)^n is more appropriate. >=20 > Jeong-dong >=20 >=20 >=20 >=20 > -----=BF=F8=BA=BB =B8=DE=BD=C3=C1=F6----- > From: "Maarten vissers" > From Date: 2012-04-02 =BF=C0=C8=C4 7:06:03 > To: "Eric Osborne (eosborne)" , "Gregory Mirsky" > , "zhang.fei3@zte.com.cn" > , "Yaacov Weingarten" , > "mpls@ietf.org" > Cc: > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 >=20 >=20 > Hi Eric, >=20 > The standard specifies the priority order of requests. E.g. in G.873.1 > (OTN linear protection, > = http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107= - > I!!PDF-E&type=3Ditems = REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following = specification is > included: >=20 > 8.3 Request type > The request types that may be reflected in the APS bytes are the > "standard" types traditionally supported by protection switching for = SONET > and SDH. These requests reflect the highest priority condition, = command, > or state (see Tables 2 and 3). In the case of unidirectional = switching, > this is the highest priority value determined from the near end only. = In > bidirectional switching, the local request will be indicated only in = the > case where it is as high or higher than any request received from the = far > end over the APS channel. In bidirectional switching, when the far end > request has the highest priority, the near end will signal Reverse > Request. > Table 2/G.873.1 ? Request/state priorities with APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Signal Fail (SF) ? protection 2 (see 8.9) > Forced Switch (FS) 3 > Signal Fail (SF) ? working 4 > Signal Degrade (SD) 5 > Manual Switch (MS) 6 > Wait-to-Restore (WTR) 7 > Exercise (EXER) 8 > Reverse Request (RR) 9 > Do Not Revert (DNR) 10 > No Request (NR) 11 (lowest) > Table 3/G.873.1 ? Request/state priorities without APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Forced Switch (FS) 2 > Signal Fail (SF) 3 > Signal Degrade (SD) 4 > Manual Switch (MS) 5 > Wait-to-Restore (WTR) 6 > Do Not Revert (DNR) 7 > No Request (NR) 8 (lowest) >=20 >=20 >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 11:56 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Maarten- >=20 > How does a node know that two requests are of equal priority? Is this > somehow configured a priori on the MSP endpoints? >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Thursday, March 29, 2012 3:06 PM > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > protection): > > > > 8.10 Equal priority requests > > In general, once a switch has been completed due to a request, it = will > not > > be overridden by another request of the same priority (first come, > first > > served behaviour). When equal priority requests occur = simultaneously, > the > > conflict is resolved in favour of the request with the lowest entity > > number. In bidirectional switching, a request received over the APS > > channel with a lower entity number will always override an identical > > priority local request with a higher entity number. Equal priority > > requests for the same entity number from both sides of a = bidirectional > > protection group are both considered valid, and equivalent to a > received > > "RR" from a near-end processing standpoint. > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Maarten vissers > > Sent: donderdag 29 maart 2012 14:54 > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > 1:n protection in a transport network at the path layer is not a = very > > common protection switching application. This is due to the fact = that > 1:n > > protection requires n+1 diverse routed paths. How many of those > diverse > > routed paths will be available in typical transport networks? Not > many... > > very often two diverse routed paths is all you can get... and this = is > only > > truly guaranteed over time if the network domain is organized as > separate > > A and a B networks. Otherwise maintenance on the network may result = in > > temporary rerouting of virtual links, resulting in routing W and P > > connections over the same fiber, node or duct. > > > > With n>2, separate networks can not be used and one has to find n+1 > > diverse routed paths through the network and guarantee that neither > > maintenance activities, nor network upgrades result in rerouting of > the > > virtual links so that W and P connections pass through the same = fiber, > > node or duct. > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line = card > > protection (end of 90's). > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Eric Osborne (eosborne) > > Sent: donderdag 29 maart 2012 14:31 > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > I still go back to my point that since only one W can ever use P, > there > > really is no such thing as 'equal priority'. We must have a = priority > > scheme, whether it is the channel number in Fpath or whether it's = some > > other mechanism, so that we know that Wi always beats Wj no matter > what > > order the events occur in. > > > > We had initially discussed leaving the exact priority scheme to the > > protection endpoints, but I see now that that may not work well = across > > vendors. > > > > I think we have a few choices: > > > > 1) some sort of explicit priority field > > 2) define priority as the FPath value, lower is better (as Maarten > > points out, this is the current practice in SDH). > > > > Either one of these have costs to them. > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and = in > > locking mode means nobody is protected until both ends converge. = This > > also makes things (potentially) very dynamic which is, I think, not > what > > we want in a protocol that has to converge in real time. > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > to > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > How > > often does this sort of thing happen in transport networks? Is it a > > real problem? > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 2:21 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > Hi Eric, > > > I agree with your logic and that current document handles scenario > you > > > present (prioties of simulteneously failed paths are different) > well. > > But > > > I still am concerned with case when priorities of Wi and Wj are > equal. > > If > > > you think that it might present a problem, then I see two possible > > ways to > > > address: > > > - disallow multiple LSPs being assigned equal priority (not the = best > > way); > > > - define tiebreaking rule(s). > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 5:11 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Let me rewrite the messages a little bit in your example. Rather > than > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > LSPs > > in > > > question. And let's also say that the priority of Wi > Wj, just = as > > you > > > have done. > > > > > > I also note that setting Path=3D=3D0 means you're using locking = mode. > > This is > > > certainly a valid case, I just want to confirm that it's your > > intention? > > > > > > at t0, no failure. > > > > > > at t1, > > > LER-A sends SF(Wi,0) to LER-Z > > > AND > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has = already > > > decided that Wi needs the protect channel. > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > t3, > > > shortly after t2. > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > unidirectional locking preemption case, as in section 3.3.3.2 of = the > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is = what > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. = Since > it > > is > > > locking, no transmission of packets takes place since neither side > had > > > ACKd the other side's SF. > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Hi Eric, > > > > Below is scenario that in my view would benefit from a = tiebreaking > > > rule. > > > > Would appreciate your consideration and feedback whether this is > > > realistic > > > > and not breaking PSC: > > > > - Assume that LSP P is not being used or used by working path of > > > priority > > > > N; > > > > - LER-A detects failure of working path Wi of priority M, where = M > > > > N, > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > - almost simulteneously, at least before it receives SF from > LER-A, > > > LER-Z > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > listing > > > Wj > > > > as Fpath; > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) = =3D=3D > > > Priority(Wj) > > > > would not change to protecting Wi path; > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason = would > > keep > > > Wi > > > > as path to protect. > > > > Is that sequence, scenario correct? Would LER-A and LER-Z = converge > > on > > > > selecting one path they'd protect? > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > priority". > > > > > There must be a tiebreaker that can handle all possible > conflicts, > > > no > > > > > matter what order or how many failures. Once there is a > > > deterministic > > > > > mechanism for all cases, it means that all LSPs are of = different > > > > priority. > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > failure > > > > of > > > > > two working paths of equal priority. Otherwise, equal priority > > would > > > > not > > > > > preempt one that is already is using the protection path, i.e. > > FIFO > > > > will > > > > > fully work in this case. > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. = In > > 1:n > > > we'd > > > > always made the assumption that, in a given protection domain, > only > > a > > > > single W can be protected at a time. To do otherwise (say, W1 = and > > W2 > > > > using P) is not possible using PSC signaling since we can only > > > indicate a > > > > single LSP in the FPath field. > > > > > > > > Nothing precludes multiple protection domains from using the = same > > > > underlying link and/or same endpoints, but that's a network = design > > > > consideration. > > > > > > > > > > > > > > > > > > > > eric > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > = = name=3DEric+Osborne+(eosborne)&fromemail=3Dryoo@etri.re.kr&messageid=3D%3= C342138 > 6c-135d-4474-ad44-01bb3bdc10b7@etri.re.kr%3E> From eosborne@cisco.com Mon Apr 2 03:57:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E9021F881A for ; Mon, 2 Apr 2012 03:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.939 X-Spam-Level: X-Spam-Status: No, score=-8.939 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEwrMLcVYQbl for ; Mon, 2 Apr 2012 03:57:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7888621F8812 for ; Mon, 2 Apr 2012 03:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=14822; q=dns/txt; s=iport; t=1333364220; x=1334573820; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=NoC+a9qli5MuIrScrGCnhUvZDmPbdQr7orE7CIfsnIc=; b=iyRtEcQj1HnCoy0HLvEvUPPw2pIpVvsH59EG7hg4tiifsI5FjCSq1Efb M5H02LaWQP0tewgY4RJkZM9GCM2J1pjHHBz3lo02Emcy6PMqmP6NQy+rI IhpUbGcFsfjSSupfSQL5qRiIfN+T0xvCKFUtz83P1qClFLhDQZfxBGXuC s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKWFeU+tJXHA/2dsb2JhbABEuQ6BB4IJAQEBAwEBAQEPAR0KNBAHBAIBCBEEAQELBhcBBgEmHwkIAgQBEggah2IFC5sinkiLGoUfYwSIWJtQgWiDBYE2AhU X-IronPort-AV: E=Sophos;i="4.75,355,1330905600"; d="scan'208";a="71276829" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 02 Apr 2012 10:57:00 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q32AuxcE009174; Mon, 2 Apr 2012 10:56:59 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Apr 2012 05:56:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Apr 2012 05:57:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAcTRoA== References: From: "Eric Osborne (eosborne)" To: "Maarten vissers" , "Gregory Mirsky" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 02 Apr 2012 10:56:59.0596 (UTC) FILETIME=[53E580C0:01CD10BF] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:57:02 -0000 I'm not sure that answers my question, although it may be that it does and I don't understand it. I think what you're talking about is the alarm hierarchy; that is, if I get both LOP and FS on the same LSP, FS 'wins'. We have this behavior in 1:1 PSC already. What we're trying to sort out with 1:n is what happens when two LSPs encounter the same failure condition. If Wx and Wy both get SF, only one of them can be protected in 1:n. In order to decide which one we need something deterministic. Talking about 'priority' and 'tie-breakers' as if they were different makes no sense in this context. If two LSPs are of the same priority due to a priority config on a network device, the tie-breaker will be something else. As you and others have suggested, we can require the nodes to rely on the signaled FPath value, standardizing the fact that the lower value is alway of better priority. The question Greg originally raised was essentially "how do we know what that priority scheme is?" Our answer heretofore in the 1:n drafts has been "depends on the device, and both devices have to agree" but the more I look at it the more that doesn't make sense. I think what we need is something akin to what you pointed out earlier is already done in MSP; lower numeric value for FPath always wins. eric > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, April 02, 2012 6:06 AM > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Eric, >=20 > The standard specifies the priority order of requests. E.g. in G.873.1 > (OTN linear protection, > = http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107= - > I!!PDF-E&type=3Ditems REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following = specification is > included: >=20 > 8.3 Request type > The request types that may be reflected in the APS bytes are the > "standard" types traditionally supported by protection switching for SONET > and SDH. These requests reflect the highest priority condition, command, > or state (see Tables 2 and 3). In the case of unidirectional switching, > this is the highest priority value determined from the near end only. In > bidirectional switching, the local request will be indicated only in the > case where it is as high or higher than any request received from the far > end over the APS channel. In bidirectional switching, when the far end > request has the highest priority, the near end will signal Reverse > Request. > Table 2/G.873.1 - Request/state priorities with APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Signal Fail (SF) - protection 2 (see 8.9) > Forced Switch (FS) 3 > Signal Fail (SF) - working 4 > Signal Degrade (SD) 5 > Manual Switch (MS) 6 > Wait-to-Restore (WTR) 7 > Exercise (EXER) 8 > Reverse Request (RR) 9 > Do Not Revert (DNR) 10 > No Request (NR) 11 (lowest) > Table 3/G.873.1 - Request/state priorities without APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Forced Switch (FS) 2 > Signal Fail (SF) 3 > Signal Degrade (SD) 4 > Manual Switch (MS) 5 > Wait-to-Restore (WTR) 6 > Do Not Revert (DNR) 7 > No Request (NR) 8 (lowest) >=20 >=20 >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 11:56 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Maarten- >=20 > How does a node know that two requests are of equal priority? Is this > somehow configured a priori on the MSP endpoints? >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Thursday, March 29, 2012 3:06 PM > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > protection): > > > > 8.10 Equal priority requests > > In general, once a switch has been completed due to a request, it will > not > > be overridden by another request of the same priority (first come, > first > > served behaviour). When equal priority requests occur simultaneously, > the > > conflict is resolved in favour of the request with the lowest entity > > number. In bidirectional switching, a request received over the APS > > channel with a lower entity number will always override an identical > > priority local request with a higher entity number. Equal priority > > requests for the same entity number from both sides of a bidirectional > > protection group are both considered valid, and equivalent to a > received > > "RR" from a near-end processing standpoint. > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Maarten vissers > > Sent: donderdag 29 maart 2012 14:54 > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > 1:n protection in a transport network at the path layer is not a very > > common protection switching application. This is due to the fact that > 1:n > > protection requires n+1 diverse routed paths. How many of those > diverse > > routed paths will be available in typical transport networks? Not > many... > > very often two diverse routed paths is all you can get... and this is > only > > truly guaranteed over time if the network domain is organized as > separate > > A and a B networks. Otherwise maintenance on the network may result in > > temporary rerouting of virtual links, resulting in routing W and P > > connections over the same fiber, node or duct. > > > > With n>2, separate networks can not be used and one has to find n+1 > > diverse routed paths through the network and guarantee that neither > > maintenance activities, nor network upgrades result in rerouting of > the > > virtual links so that W and P connections pass through the same fiber, > > node or duct. > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line card > > protection (end of 90's). > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Eric Osborne (eosborne) > > Sent: donderdag 29 maart 2012 14:31 > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > I still go back to my point that since only one W can ever use P, > there > > really is no such thing as 'equal priority'. We must have a priority > > scheme, whether it is the channel number in Fpath or whether it's some > > other mechanism, so that we know that Wi always beats Wj no matter > what > > order the events occur in. > > > > We had initially discussed leaving the exact priority scheme to the > > protection endpoints, but I see now that that may not work well across > > vendors. > > > > I think we have a few choices: > > > > 1) some sort of explicit priority field > > 2) define priority as the FPath value, lower is better (as Maarten > > points out, this is the current practice in SDH). > > > > Either one of these have costs to them. > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in > > locking mode means nobody is protected until both ends converge. This > > also makes things (potentially) very dynamic which is, I think, not > what > > we want in a protocol that has to converge in real time. > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > to > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > How > > often does this sort of thing happen in transport networks? Is it a > > real problem? > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 2:21 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > Hi Eric, > > > I agree with your logic and that current document handles scenario > you > > > present (prioties of simulteneously failed paths are different) > well. > > But > > > I still am concerned with case when priorities of Wi and Wj are > equal. > > If > > > you think that it might present a problem, then I see two possible > > ways to > > > address: > > > - disallow multiple LSPs being assigned equal priority (not the best > > way); > > > - define tiebreaking rule(s). > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 5:11 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Let me rewrite the messages a little bit in your example. Rather > than > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > LSPs > > in > > > question. And let's also say that the priority of Wi > Wj, just as > > you > > > have done. > > > > > > I also note that setting Path=3D=3D0 means you're using locking = mode. > > This is > > > certainly a valid case, I just want to confirm that it's your > > intention? > > > > > > at t0, no failure. > > > > > > at t1, > > > LER-A sends SF(Wi,0) to LER-Z > > > AND > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > > > decided that Wi needs the protect channel. > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > t3, > > > shortly after t2. > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > unidirectional locking preemption case, as in section 3.3.3.2 of the > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. Since > it > > is > > > locking, no transmission of packets takes place since neither side > had > > > ACKd the other side's SF. > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Hi Eric, > > > > Below is scenario that in my view would benefit from a tiebreaking > > > rule. > > > > Would appreciate your consideration and feedback whether this is > > > realistic > > > > and not breaking PSC: > > > > - Assume that LSP P is not being used or used by working path of > > > priority > > > > N; > > > > - LER-A detects failure of working path Wi of priority M, where M > > > > N, > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > - almost simulteneously, at least before it receives SF from > LER-A, > > > LER-Z > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > listing > > > Wj > > > > as Fpath; > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) = =3D=3D > > > Priority(Wj) > > > > would not change to protecting Wi path; > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason would > > keep > > > Wi > > > > as path to protect. > > > > Is that sequence, scenario correct? Would LER-A and LER-Z converge > > on > > > > selecting one path they'd protect? > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > priority". > > > > > There must be a tiebreaker that can handle all possible > conflicts, > > > no > > > > > matter what order or how many failures. Once there is a > > > deterministic > > > > > mechanism for all cases, it means that all LSPs are of different > > > > priority. > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > failure > > > > of > > > > > two working paths of equal priority. Otherwise, equal priority > > would > > > > not > > > > > preempt one that is already is using the protection path, i.e. > > FIFO > > > > will > > > > > fully work in this case. > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. In > > 1:n > > > we'd > > > > always made the assumption that, in a given protection domain, > only > > a > > > > single W can be protected at a time. To do otherwise (say, W1 and > > W2 > > > > using P) is not possible using PSC signaling since we can only > > > indicate a > > > > single LSP in the FPath field. > > > > > > > > Nothing precludes multiple protection domains from using the same > > > > underlying link and/or same endpoints, but that's a network design > > > > consideration. > > > > > > > > > > > > > > > > > > > > eric > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 From maarten.vissers@huawei.com Mon Apr 2 04:37:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B545221F8959 for ; Mon, 2 Apr 2012 04:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=-2.251, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKUUrwaNYXbt for ; Mon, 2 Apr 2012 04:37:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 474A921F88E6 for ; Mon, 2 Apr 2012 04:37:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEO77533; Mon, 02 Apr 2012 07:37:22 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 04:35:13 -0700 Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 04:34:59 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.01.0323.003; Mon, 2 Apr 2012 12:34:56 +0100 From: Maarten vissers To: "Eric Osborne (eosborne)" , =?ks_c_5601-1987?B?t/nBpLW/?= , Gregory Mirsky , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAP3CaQAAtpRQAAAgxoA= Date: Mon, 2 Apr 2012 11:34:16 +0000 Message-ID: References: <6AB52EA5AA7B4A4F81C6DC3AFF6D7FCA@etri.info> In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.112.103] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 11:37:23 -0000 KDE6MSlebiBpcyBhbHNvIHVzZWQgaW4gTVBMUy1UUCdzIDE6biBwcm90ZWN0aW9uLi4uDQoNCkR1 ZSB0byB0aGUgdXNlIG9mIGEgU1BNRSBhcyBtZWFucyB0byBpbXBsZW1lbnQgUFcgb3IgTFNQIFRD TSwgdGhlcmUgZXhpc3RzIGEgY2xpZW50L3NlcnZlci1saWtlIHJlbGF0aW9uc2hpcCBiZXR3ZWVu IHRoZSBvcmlnaW5hbCBQVyBhbmQgdGhlIFNQTUUsIG9yIHRoZSBvcmlnaW5hbCBMU1AgYW5kIHRo ZSBTUE1FLiANCg0KVGhpcyBjbGllbnQvc2VydmVyLWxpa2UgcmVsYXRpb25zaGlwIHN1cHBvcnRz IGFnZ3JlZ2F0aW9uIG9mIHRoZSBuIFByb3RlY3Rpb24gUFcgW24gUHJvdGVjdGlvbiBMU1BdIHNp Z25hbHMgaW50byBhIHNpbmdsZSBQcm90ZWN0aW9uIFNQTUUgc2lnbmFsLiANCg0KQXQgdGhlIFNQ TUUgbGV2ZWwgeW91IG5vdyBoYXZlIGEgMTpuIHByb3RlY3Rpb24gYXJjaGl0ZWN0dXJlLCB3aGls ZSBhdCB0aGUgb3JpZ2luYWwgUFcgW0xTUF0gbGV2ZWwgeW91IGhhdmUgYSAoMToxKV5uIHByb3Rl Y3Rpb24gYXJjaGl0ZWN0dXJlIHZhcmlhbnQgaW4gd2hpY2ggdGhlIHByb3RlY3Rpb24gY29ubmVj dGlvbiBtb25pdG9yaW5nIGlzIG5vdCBwZXJmb3JtZWQgb24gYSBwZXIgUFcgW0xTUF0gcHJvdGVj dGlvbiBjb25uZWN0aW9uIFsoMToxKV5uIFNOQy9TXSwgYnV0IGluc3RlYWQgb24gdGhlIHNlcnZl ci1saWtlIFNQTUUgcHJvdGVjdGlvbiBjb25uZWN0aW9uIFsoMToxKV5uIFNOQ0cvSV0uIEkgc3Vn Z2VzdCB0aGF0IHdlIGFkZCB0aGlzICgxOjEpXm4gU05DRy9JIHRvIEcuODA4LjEuDQoNClJlZ2Fy ZHMsDQpNYWFydGVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBFcmljIE9z Ym9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5lQGNpc2NvLmNvbV0gDQpTZW50OiBtYWFu ZGFnIDIgYXByaWwgMjAxMiAxMjo1MA0KVG86ILf5waS1vzsgTWFhcnRlbiB2aXNzZXJzOyBHcmVn b3J5IE1pcnNreTsgemhhbmcuZmVpM0B6dGUuY29tLmNuOyBZYWFjb3YgV2VpbmdhcnRlbjsgbXBs c0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFJlOiBbbXBsc10gQ29tbWVudHMgb24gZHJhZnQtZXp5 LW1wbHMtMXRvbi1wcm90ZWN0aW9uLTAxDQoNClN1cmUsIGJ1dCB3aGF0IHdlJ3JlIHRyeWluZyB0 byBhZGRyZXNzIGhlcmUgaXMgdGhlIHJlcXVpcmVtZW50IGZvciAxOm4uDQoNCkFzIEkgdW5kZXJz dGFuZCAoMToxKV5uIGl0J3MganVzdCBhIHNldCBvZiAxOjEgcHJvdGVjdGlvbiBzZXNzaW9ucyBw cm92aXNpb25lZCBieSBzb21lIGNlbnRyYWwgYm94IHdpdGgga25vd2xlZGdlIG9mIHRoZSBwb3Rl bnRpYWwgY29uZmxpY3RzIGJldHdlZW4gb3RoZXIgYm94ZXMuICBUaGlzIGlzbid0IHNvbWV0aGlu ZyB3ZSBuZWVkIG5ldyBzdGF0ZSBtYWNoaW5lcyBvciBwYWNrZXQgZm9ybWF0cyBmb3IsIGFuZCB0 aHVzIGRvZXNuJ3Qgc2VlbSBsaWtlIHNvbWV0aGluZyB3ZSBuZWVkIHRvIHN0YW5kYXJkaXplLiAg RlJSLCBhbHRob3VnaCBpdCBpcyBkaWZmZXJlbnQgZnJvbSBhbnkgb2YgdGhlIHRyYW5zcG9ydC1z dHlsZSBwcm90ZWN0aW9uIG1ldGhvZHMsIGhhcyBiZWVuIHByb3Zpc2lvbmVkIGxpa2UgdGhpcyBm b3IgeWVhcnMuDQoNCg0KDQplcmljDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogt/nBpLW/IFttYWlsdG86cnlvb0BldHJpLnJlLmtyXQ0KPiBTZW50OiBNb25kYXksIEFw cmlsIDAyLCAyMDEyIDY6MjggQU0NCj4gVG86IE1hYXJ0ZW4gdmlzc2VyczsgRXJpYyBPc2Jvcm5l IChlb3Nib3JuZSk7IEdyZWdvcnkgTWlyc2t5Ow0KPiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IFlh YWNvdiBXZWluZ2FydGVuOyBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBSZTogW21wbHNd IENvbW1lbnRzIG9uIGRyYWZ0LWV6eS1tcGxzLTF0b24tcHJvdGVjdGlvbi0wMQ0KPiANCj4gSGks DQo+IA0KPiBGb3IgcGFja2V0IG5ldHdvcmtzLCBpZiBvbmUgZXZlciB3YW50cyB0byBoYXZlIG4g d29ya2luZyBjb25uZWN0aW9ucyBiZQ0KPiBwcm90ZWN0ZWQgYnkgMSBwcm90ZWN0aW9uIGNvbm5l Y3Rpb24sDQo+ICgxOjEpXm4gaXMgbW9yZSBhcHByb3ByaWF0ZS4NCj4gDQo+IEplb25nLWRvbmcN Cj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tv/i6uyC43r3DwfYtLS0tLQ0KPiBGcm9tOiAiTWFhcnRl biB2aXNzZXJzIiA8bWFhcnRlbi52aXNzZXJzQGh1YXdlaS5jb20+DQo+IEZyb20gRGF0ZTogMjAx Mi0wNC0wMiC/wMjEIDc6MDY6MDMNCj4gVG86ICJFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSIgPGVv c2Jvcm5lQGNpc2NvLmNvbT4sICJHcmVnb3J5IE1pcnNreSINCj4gPGdyZWdvcnkubWlyc2t5QGVy aWNzc29uLmNvbT4sICJ6aGFuZy5mZWkzQHp0ZS5jb20uY24iDQo+IDx6aGFuZy5mZWkzQHp0ZS5j b20uY24+LCAiWWFhY292IFdlaW5nYXJ0ZW4iIDx3eWFhY292QGdtYWlsLmNvbT4sDQo+ICJtcGxz QGlldGYub3JnIiA8bXBsc0BpZXRmLm9yZz4NCj4gQ2M6DQo+IFN1YmplY3Q6IFJlOiBbbXBsc10g Q29tbWVudHMgb24gZHJhZnQtZXp5LW1wbHMtMXRvbi1wcm90ZWN0aW9uLTAxDQo+IA0KPiANCj4g SGkgRXJpYywNCj4gDQo+IFRoZSBzdGFuZGFyZCBzcGVjaWZpZXMgdGhlIHByaW9yaXR5IG9yZGVy IG9mIHJlcXVlc3RzLiBFLmcuIGluIEcuODczLjENCj4gKE9UTiBsaW5lYXIgcHJvdGVjdGlvbiwN Cj4gaHR0cDovL3d3dy5pdHUuaW50L3JlYy9kb2xvZ2luX3B1Yi5hc3A/bGFuZz1lJmlkPVQtUkVD LUcuODczLjEtMjAxMTA3LQ0KPiBJISFQREYtRSZ0eXBlPWl0ZW1zIDxodHRwOi8vd3d3Lml0dS5p bnQvcmVjL2RvbG9naW5fcHViLmFzcD9sYW5nPWUmaWQ9VC0NCj4gUkVDLUcuODczLjEtMjAxMTA3 LUkhIVBERi1FJnR5cGU9aXRlbXM+ICkgdGhlIGZvbGxvd2luZyBzcGVjaWZpY2F0aW9uIGlzDQo+ IGluY2x1ZGVkOg0KPiANCj4gOC4zICAgICBSZXF1ZXN0IHR5cGUNCj4gVGhlIHJlcXVlc3QgdHlw ZXMgdGhhdCBtYXkgYmUgcmVmbGVjdGVkIGluIHRoZSBBUFMgYnl0ZXMgYXJlIHRoZQ0KPiAic3Rh bmRhcmQiIHR5cGVzIHRyYWRpdGlvbmFsbHkgc3VwcG9ydGVkIGJ5IHByb3RlY3Rpb24gc3dpdGNo aW5nIGZvciBTT05FVA0KPiBhbmQgU0RILiBUaGVzZSByZXF1ZXN0cyByZWZsZWN0IHRoZSBoaWdo ZXN0IHByaW9yaXR5IGNvbmRpdGlvbiwgY29tbWFuZCwNCj4gb3Igc3RhdGUgKHNlZSBUYWJsZXMg MiBhbmQgMykuIEluIHRoZSBjYXNlIG9mIHVuaWRpcmVjdGlvbmFsIHN3aXRjaGluZywNCj4gdGhp cyBpcyB0aGUgaGlnaGVzdCBwcmlvcml0eSB2YWx1ZSBkZXRlcm1pbmVkIGZyb20gdGhlIG5lYXIg ZW5kIG9ubHkuIEluDQo+IGJpZGlyZWN0aW9uYWwgc3dpdGNoaW5nLCB0aGUgbG9jYWwgcmVxdWVz dCB3aWxsIGJlIGluZGljYXRlZCBvbmx5IGluIHRoZQ0KPiBjYXNlIHdoZXJlIGl0IGlzIGFzIGhp Z2ggb3IgaGlnaGVyIHRoYW4gYW55IHJlcXVlc3QgcmVjZWl2ZWQgZnJvbSB0aGUgZmFyDQo+IGVu ZCBvdmVyIHRoZSBBUFMgY2hhbm5lbC4gSW4gYmlkaXJlY3Rpb25hbCBzd2l0Y2hpbmcsIHdoZW4g dGhlIGZhciBlbmQNCj4gcmVxdWVzdCBoYXMgdGhlIGhpZ2hlc3QgcHJpb3JpdHksIHRoZSBuZWFy IGVuZCB3aWxsIHNpZ25hbCBSZXZlcnNlDQo+IFJlcXVlc3QuDQo+IFRhYmxlIDIvRy44NzMuMSA/ IFJlcXVlc3Qvc3RhdGUgcHJpb3JpdGllcyB3aXRoIEFQUyBwcm90b2NvbA0KPiBSZXF1ZXN0L3N0 YXRlCSBQcmlvcml0eQ0KPiBMb2Nrb3V0IGZvciBQcm90ZWN0aW9uIChMb1ApCSAxIChoaWdoZXN0 KQ0KPiBTaWduYWwgRmFpbCAoU0YpID8gcHJvdGVjdGlvbgkgMiAoc2VlIDguOSkNCj4gRm9yY2Vk IFN3aXRjaCAoRlMpCSAzDQo+IFNpZ25hbCBGYWlsIChTRikgPyB3b3JraW5nCSA0DQo+IFNpZ25h bCBEZWdyYWRlIChTRCkJIDUNCj4gTWFudWFsIFN3aXRjaCAoTVMpCSA2DQo+IFdhaXQtdG8tUmVz dG9yZSAoV1RSKQkgNw0KPiBFeGVyY2lzZSAoRVhFUikJIDgNCj4gUmV2ZXJzZSBSZXF1ZXN0IChS UikJIDkNCj4gRG8gTm90IFJldmVydCAoRE5SKQkgMTANCj4gTm8gUmVxdWVzdCAoTlIpCSAxMSAo bG93ZXN0KQ0KPiBUYWJsZSAzL0cuODczLjEgPyBSZXF1ZXN0L3N0YXRlIHByaW9yaXRpZXMgd2l0 aG91dCBBUFMgcHJvdG9jb2wNCj4gUmVxdWVzdC9zdGF0ZQkgUHJpb3JpdHkNCj4gTG9ja291dCBm b3IgUHJvdGVjdGlvbiAoTG9QKQkgMSAoaGlnaGVzdCkNCj4gRm9yY2VkIFN3aXRjaCAoRlMpCSAy DQo+IFNpZ25hbCBGYWlsIChTRikJIDMNCj4gU2lnbmFsIERlZ3JhZGUgKFNEKQkgNA0KPiBNYW51 YWwgU3dpdGNoIChNUykJIDUNCj4gV2FpdC10by1SZXN0b3JlIChXVFIpCSA2DQo+IERvIE5vdCBS ZXZlcnQgKEROUikJIDcNCj4gTm8gUmVxdWVzdCAoTlIpCSA4IChsb3dlc3QpDQo+IA0KPiANCj4g DQo+IFJlZ2FyZHMsDQo+IE1hYXJ0ZW4NCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVvc2Jvcm5lQGNp c2NvLmNvbV0NCj4gU2VudDogbWFhbmRhZyAyIGFwcmlsIDIwMTIgMTE6NTYNCj4gVG86IE1hYXJ0 ZW4gdmlzc2VyczsgR3JlZ29yeSBNaXJza3k7IHpoYW5nLmZlaTNAenRlLmNvbS5jbjsgWWFhY292 DQo+IFdlaW5nYXJ0ZW47IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IENvbW1lbnRzIG9u IGRyYWZ0LWV6eS1tcGxzLTF0b24tcHJvdGVjdGlvbi0wMQ0KPiANCj4gSGkgTWFhcnRlbi0NCj4g DQo+IEhvdyBkb2VzIGEgbm9kZSBrbm93IHRoYXQgdHdvIHJlcXVlc3RzIGFyZSBvZiBlcXVhbCBw cmlvcml0eT8gIElzIHRoaXMNCj4gc29tZWhvdyBjb25maWd1cmVkIGEgcHJpb3JpIG9uIHRoZSBN U1AgZW5kcG9pbnRzPw0KPiANCj4gDQo+IA0KPiANCj4gZXJpYw0KPiANCj4gDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBNYWFydGVuIHZpc3NlcnMgW21haWx0bzpt YWFydGVuLnZpc3NlcnNAaHVhd2VpLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjks IDIwMTIgMzowNiBQTQ0KPiA+IFRvOiBNYWFydGVuIHZpc3NlcnM7IEVyaWMgT3Nib3JuZSAoZW9z Ym9ybmUpOyBHcmVnb3J5IE1pcnNreTsNCj4gPiB6aGFuZy5mZWkzQHp0ZS5jb20uY247IFlhYWNv diBXZWluZ2FydGVuOyBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IENvbW1lbnRzIG9u IGRyYWZ0LWV6eS1tcGxzLTF0b24tcHJvdGVjdGlvbi0wMQ0KPiA+DQo+ID4gQmVsb3cgaXMgYSBj b3B5IG9mIHRoZSBlcXVhbCBwcmlvcml0eSB0ZXh0IGluIEcuODczLjEgKE9UTiBsaW5lYXINCj4g PiBwcm90ZWN0aW9uKToNCj4gPg0KPiA+IDguMTAgIEVxdWFsIHByaW9yaXR5IHJlcXVlc3RzDQo+ ID4gSW4gZ2VuZXJhbCwgb25jZSBhIHN3aXRjaCBoYXMgYmVlbiBjb21wbGV0ZWQgZHVlIHRvIGEg cmVxdWVzdCwgaXQgd2lsbA0KPiBub3QNCj4gPiBiZSBvdmVycmlkZGVuIGJ5IGFub3RoZXIgcmVx dWVzdCBvZiB0aGUgc2FtZSBwcmlvcml0eSAoZmlyc3QgY29tZSwNCj4gZmlyc3QNCj4gPiBzZXJ2 ZWQgYmVoYXZpb3VyKS4gV2hlbiBlcXVhbCBwcmlvcml0eSByZXF1ZXN0cyBvY2N1ciBzaW11bHRh bmVvdXNseSwNCj4gdGhlDQo+ID4gY29uZmxpY3QgaXMgcmVzb2x2ZWQgaW4gZmF2b3VyIG9mIHRo ZSByZXF1ZXN0IHdpdGggdGhlIGxvd2VzdCBlbnRpdHkNCj4gPiBudW1iZXIuIEluIGJpZGlyZWN0 aW9uYWwgc3dpdGNoaW5nLCBhIHJlcXVlc3QgcmVjZWl2ZWQgb3ZlciB0aGUgQVBTDQo+ID4gY2hh bm5lbCB3aXRoIGEgbG93ZXIgZW50aXR5IG51bWJlciB3aWxsIGFsd2F5cyBvdmVycmlkZSBhbiBp ZGVudGljYWwNCj4gPiBwcmlvcml0eSBsb2NhbCByZXF1ZXN0IHdpdGggYSBoaWdoZXIgZW50aXR5 IG51bWJlci4gRXF1YWwgcHJpb3JpdHkNCj4gPiByZXF1ZXN0cyBmb3IgdGhlIHNhbWUgZW50aXR5 IG51bWJlciBmcm9tIGJvdGggc2lkZXMgb2YgYSBiaWRpcmVjdGlvbmFsDQo+ID4gcHJvdGVjdGlv biBncm91cCBhcmUgYm90aCBjb25zaWRlcmVkIHZhbGlkLCBhbmQgZXF1aXZhbGVudCB0byBhDQo+ IHJlY2VpdmVkDQo+ID4gIlJSIiBmcm9tIGEgbmVhci1lbmQgcHJvY2Vzc2luZyBzdGFuZHBvaW50 Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBNYWFydGVuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4gTWFhcnRlbiB2aXNzZXJz DQo+ID4gU2VudDogZG9uZGVyZGFnIDI5IG1hYXJ0IDIwMTIgMTQ6NTQNCj4gPiBUbzogRXJpYyBP c2Jvcm5lIChlb3Nib3JuZSk7IEdyZWdvcnkgTWlyc2t5OyB6aGFuZy5mZWkzQHp0ZS5jb20uY247 DQo+IFlhYWNvdg0KPiA+IFdlaW5nYXJ0ZW47IG1wbHNAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogW21wbHNdIENvbW1lbnRzIG9uIGRyYWZ0LWV6eS1tcGxzLTF0b24tcHJvdGVjdGlvbi0wMQ0K PiA+DQo+ID4gMTpuIHByb3RlY3Rpb24gaW4gYSB0cmFuc3BvcnQgbmV0d29yayBhdCB0aGUgcGF0 aCBsYXllciBpcyBub3QgYSB2ZXJ5DQo+ID4gY29tbW9uIHByb3RlY3Rpb24gc3dpdGNoaW5nIGFw cGxpY2F0aW9uLiBUaGlzIGlzIGR1ZSB0byB0aGUgZmFjdCB0aGF0DQo+IDE6bg0KPiA+IHByb3Rl Y3Rpb24gcmVxdWlyZXMgbisxIGRpdmVyc2Ugcm91dGVkIHBhdGhzLiBIb3cgbWFueSBvZiB0aG9z ZQ0KPiBkaXZlcnNlDQo+ID4gcm91dGVkIHBhdGhzIHdpbGwgYmUgYXZhaWxhYmxlIGluIHR5cGlj YWwgdHJhbnNwb3J0IG5ldHdvcmtzPyBOb3QNCj4gbWFueS4uLg0KPiA+IHZlcnkgb2Z0ZW4gdHdv IGRpdmVyc2Ugcm91dGVkIHBhdGhzIGlzIGFsbCB5b3UgY2FuIGdldC4uLiBhbmQgdGhpcyBpcw0K PiBvbmx5DQo+ID4gdHJ1bHkgZ3VhcmFudGVlZCBvdmVyIHRpbWUgaWYgdGhlIG5ldHdvcmsgZG9t YWluIGlzIG9yZ2FuaXplZCBhcw0KPiBzZXBhcmF0ZQ0KPiA+IEEgYW5kIGEgQiBuZXR3b3Jrcy4g T3RoZXJ3aXNlIG1haW50ZW5hbmNlIG9uIHRoZSBuZXR3b3JrIG1heSByZXN1bHQgaW4NCj4gPiB0 ZW1wb3JhcnkgcmVyb3V0aW5nIG9mIHZpcnR1YWwgbGlua3MsIHJlc3VsdGluZyBpbiByb3V0aW5n IFcgYW5kIFANCj4gPiBjb25uZWN0aW9ucyBvdmVyIHRoZSBzYW1lIGZpYmVyLCBub2RlIG9yIGR1 Y3QuDQo+ID4NCj4gPiBXaXRoIG4+Miwgc2VwYXJhdGUgbmV0d29ya3MgY2FuIG5vdCBiZSB1c2Vk IGFuZCBvbmUgaGFzIHRvIGZpbmQgbisxDQo+ID4gZGl2ZXJzZSByb3V0ZWQgcGF0aHMgdGhyb3Vn aCB0aGUgbmV0d29yayBhbmQgZ3VhcmFudGVlIHRoYXQgbmVpdGhlcg0KPiA+IG1haW50ZW5hbmNl IGFjdGl2aXRpZXMsIG5vciBuZXR3b3JrIHVwZ3JhZGVzIHJlc3VsdCBpbiByZXJvdXRpbmcgb2YN Cj4gdGhlDQo+ID4gdmlydHVhbCBsaW5rcyBzbyB0aGF0IFcgYW5kIFAgY29ubmVjdGlvbnMgcGFz cyB0aHJvdWdoIHRoZSBzYW1lIGZpYmVyLA0KPiA+IG5vZGUgb3IgZHVjdC4NCj4gPg0KPiA+IDE6 biBwcm90ZWN0aW9uIGhhcyBiZWVuIHVzZWQgaW4gU0RIL1NPTkVUIGZvciBTREgvU09ORVQgcmVn ZW5lcmF0b3INCj4gPiBwcm90ZWN0aW9uICgxOjcgYW5kIDE6MTEgc3lzdGVtcywgaW4gZWFybHkg OTAncykgYW5kIGZvciBTREggbGluZSBjYXJkDQo+ID4gcHJvdGVjdGlvbiAoZW5kIG9mIDkwJ3Mp Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBNYWFydGVuDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG1wbHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm1w bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mDQo+ID4gRXJpYyBPc2Jvcm5lIChl b3Nib3JuZSkNCj4gPiBTZW50OiBkb25kZXJkYWcgMjkgbWFhcnQgMjAxMiAxNDozMQ0KPiA+IFRv OiBHcmVnb3J5IE1pcnNreTsgemhhbmcuZmVpM0B6dGUuY29tLmNuOyBZYWFjb3YgV2VpbmdhcnRl bjsNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFttcGxzXSBDb21tZW50cyBv biBkcmFmdC1lenktbXBscy0xdG9uLXByb3RlY3Rpb24tMDENCj4gPg0KPiA+IEkgc3RpbGwgZ28g YmFjayB0byBteSBwb2ludCB0aGF0IHNpbmNlIG9ubHkgb25lIFcgY2FuIGV2ZXIgdXNlIFAsDQo+ IHRoZXJlDQo+ID4gcmVhbGx5IGlzIG5vIHN1Y2ggdGhpbmcgYXMgJ2VxdWFsIHByaW9yaXR5Jy4g IFdlIG11c3QgaGF2ZSBhIHByaW9yaXR5DQo+ID4gc2NoZW1lLCB3aGV0aGVyIGl0IGlzIHRoZSBj aGFubmVsIG51bWJlciBpbiBGcGF0aCBvciB3aGV0aGVyIGl0J3Mgc29tZQ0KPiA+IG90aGVyIG1l Y2hhbmlzbSwgc28gdGhhdCB3ZSBrbm93IHRoYXQgV2kgYWx3YXlzIGJlYXRzIFdqIG5vIG1hdHRl cg0KPiB3aGF0DQo+ID4gb3JkZXIgdGhlIGV2ZW50cyBvY2N1ciBpbi4NCj4gPg0KPiA+IFdlIGhh ZCBpbml0aWFsbHkgZGlzY3Vzc2VkIGxlYXZpbmcgdGhlIGV4YWN0IHByaW9yaXR5IHNjaGVtZSB0 byB0aGUNCj4gPiBwcm90ZWN0aW9uIGVuZHBvaW50cywgYnV0IEkgc2VlIG5vdyB0aGF0IHRoYXQg bWF5IG5vdCB3b3JrIHdlbGwgYWNyb3NzDQo+ID4gdmVuZG9ycy4NCj4gPg0KPiA+IEkgdGhpbmsg d2UgaGF2ZSBhIGZldyBjaG9pY2VzOg0KPiA+DQo+ID4gMSkgc29tZSBzb3J0IG9mIGV4cGxpY2l0 IHByaW9yaXR5IGZpZWxkDQo+ID4gMikgZGVmaW5lIHByaW9yaXR5IGFzIHRoZSBGUGF0aCB2YWx1 ZSwgbG93ZXIgaXMgYmV0dGVyIChhcyBNYWFydGVuDQo+ID4gcG9pbnRzIG91dCwgdGhpcyBpcyB0 aGUgY3VycmVudCBwcmFjdGljZSBpbiBTREgpLg0KPiA+DQo+ID4gRWl0aGVyIG9uZSBvZiB0aGVz ZSBoYXZlIGNvc3RzIHRvIHRoZW0uDQo+ID4NCj4gPiBEb2luZyAjMSBsZWF2ZXMgdXMgd2l0aCBh IHBvdGVudGlhbCBtaXNtYXRjaDsgaWYgTEVSLUEgdGhpbmtzIFcyIGhhcw0KPiA+IHByaW8xIGFu ZCBMRVItWiB0aGlua3MgVzMgaGFzIHByaW8xLCBzb3J0aW5nIHRoaXMgb3V0IGlzIG1lc3N5LCBh bmQgaW4NCj4gPiBsb2NraW5nIG1vZGUgbWVhbnMgbm9ib2R5IGlzIHByb3RlY3RlZCB1bnRpbCBi b3RoIGVuZHMgY29udmVyZ2UuICBUaGlzDQo+ID4gYWxzbyBtYWtlcyB0aGluZ3MgKHBvdGVudGlh bGx5KSB2ZXJ5IGR5bmFtaWMgd2hpY2ggaXMsIEkgdGhpbmssIG5vdA0KPiB3aGF0DQo+ID4gd2Ug d2FudCBpbiBhIHByb3RvY29sIHRoYXQgaGFzIHRvIGNvbnZlcmdlIGluIHJlYWwgdGltZS4NCj4g Pg0KPiA+IERvaW5nICMyIG1lYW5zIHRoYXQgaWYgSSBoYXZlIFcxLi4uVzUgYWxyZWFkeSBwcm92 aXNpb25lZCBhbmQgSSB3YW50DQo+IHRvDQo+ID4gYWRkIFczLjEsIEkgbmVlZCB0byByZXByb3Zp c2lvbiBXNCBhbmQgVzUsIHdoaWNoIG1heSBiZSBkaXNydXB0aXZlLg0KPiBIb3cNCj4gPiBvZnRl biBkb2VzIHRoaXMgc29ydCBvZiB0aGluZyBoYXBwZW4gaW4gdHJhbnNwb3J0IG5ldHdvcmtzPyAg SXMgaXQgYQ0KPiA+IHJlYWwgcHJvYmxlbT8NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IGVyaWMN Cj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IEdyZWdv cnkgTWlyc2t5IFttYWlsdG86Z3JlZ29yeS5taXJza3lAZXJpY3Nzb24uY29tXQ0KPiA+ID4gU2Vu dDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDEyIDI6MjEgUE0NCj4gPiA+IFRvOiBFcmljIE9zYm9y bmUgKGVvc2Jvcm5lKTsgemhhbmcuZmVpM0B6dGUuY29tLmNuOyBZYWFjb3YNCj4gV2VpbmdhcnRl bjsNCj4gPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJFOiBDb21tZW50cyBvbiBk cmFmdC1lenktbXBscy0xdG9uLXByb3RlY3Rpb24tMDENCj4gPiA+DQo+ID4gPg0KPiA+ID4gSGkg RXJpYywNCj4gPiA+IEkgYWdyZWUgd2l0aCB5b3VyIGxvZ2ljIGFuZCB0aGF0IGN1cnJlbnQgZG9j dW1lbnQgaGFuZGxlcyBzY2VuYXJpbw0KPiB5b3UNCj4gPiA+IHByZXNlbnQgKHByaW90aWVzIG9m IHNpbXVsdGVuZW91c2x5IGZhaWxlZCBwYXRocyBhcmUgZGlmZmVyZW50KQ0KPiB3ZWxsLg0KPiA+ IEJ1dA0KPiA+ID4gSSBzdGlsbCBhbSBjb25jZXJuZWQgd2l0aCBjYXNlIHdoZW4gcHJpb3JpdGll cyBvZiBXaSBhbmQgV2ogYXJlDQo+IGVxdWFsLg0KPiA+IElmDQo+ID4gPiB5b3UgdGhpbmsgdGhh dCBpdCBtaWdodCBwcmVzZW50IGEgcHJvYmxlbSwgdGhlbiBJIHNlZSB0d28gcG9zc2libGUNCj4g PiB3YXlzIHRvDQo+ID4gPiBhZGRyZXNzOg0KPiA+ID4gLSBkaXNhbGxvdyBtdWx0aXBsZSBMU1Bz IGJlaW5nIGFzc2lnbmVkIGVxdWFsIHByaW9yaXR5IChub3QgdGhlIGJlc3QNCj4gPiB3YXkpOw0K PiA+ID4gLSBkZWZpbmUgdGllYnJlYWtpbmcgcnVsZShzKS4NCj4gPiA+DQo+ID4gPiAgICAgIFJl Z2FyZHMsDQo+ID4gPiAgICAgICAgICAgICAgR3JlZw0KPiA+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFp bHRvOmVvc2Jvcm5lQGNpc2NvLmNvbV0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyOSwg MjAxMiA1OjExIEFNDQo+ID4gPiBUbzogR3JlZ29yeSBNaXJza3k7IHpoYW5nLmZlaTNAenRlLmNv bS5jbjsgWWFhY292IFdlaW5nYXJ0ZW47DQo+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiBTdWJq ZWN0OiBSRTogQ29tbWVudHMgb24gZHJhZnQtZXp5LW1wbHMtMXRvbi1wcm90ZWN0aW9uLTAxDQo+ ID4gPg0KPiA+ID4gTGV0IG1lIHJld3JpdGUgdGhlIG1lc3NhZ2VzIGEgbGl0dGxlIGJpdCBpbiB5 b3VyIGV4YW1wbGUuICBSYXRoZXINCj4gdGhhbg0KPiA+ID4gU0YoMSwwKSwgbGV0J3MgdXNlIFNG KFdpLDApIG9yIFNmKFdqLDApLCB3aGVyZSBXaSBhbmQgV2ogYXJlIHRoZQ0KPiBMU1BzDQo+ID4g aW4NCj4gPiA+IHF1ZXN0aW9uLiAgQW5kIGxldCdzIGFsc28gc2F5IHRoYXQgdGhlIHByaW9yaXR5 IG9mIFdpID4gV2osIGp1c3QgYXMNCj4gPiB5b3UNCj4gPiA+IGhhdmUgZG9uZS4NCj4gPiA+DQo+ ID4gPiBJIGFsc28gbm90ZSB0aGF0IHNldHRpbmcgUGF0aD09MCBtZWFucyB5b3UncmUgdXNpbmcg bG9ja2luZyBtb2RlLg0KPiA+IFRoaXMgaXMNCj4gPiA+IGNlcnRhaW5seSBhIHZhbGlkIGNhc2Us IEkganVzdCB3YW50IHRvIGNvbmZpcm0gdGhhdCBpdCdzIHlvdXINCj4gPiBpbnRlbnRpb24/DQo+ ID4gPg0KPiA+ID4gYXQgdDAsIG5vIGZhaWx1cmUuDQo+ID4gPg0KPiA+ID4gYXQgdDEsDQo+ID4g PiAgIExFUi1BIHNlbmRzIFNGKFdpLDApIHRvIExFUi1aDQo+ID4gPiAgICAgQU5EDQo+ID4gPiAg IExFUi1aIHNlbmRzIFNGKFdqLDApIHRvIExFUi1aDQo+ID4gPg0KPiA+ID4gYXQgdDIsIExFUi1B IHJlY2VpdmVzIFNGKFdqLDApLiAgSXQgaWdub3JlcyBpdCwgc2luY2UgaXQgaGFzIGFscmVhZHkN Cj4gPiA+IGRlY2lkZWQgdGhhdCBXaSBuZWVkcyB0aGUgcHJvdGVjdCBjaGFubmVsLg0KPiA+ID4N Cj4gPiA+IExFUi1aIGFsc28gcmVjZWl2ZXMgU0YoV2ksMCkuICBUaGlzIGlzIGVpdGhlciBleGFj dGx5IGF0IHQyLCBvciBhdA0KPiB0MywNCj4gPiA+IHNob3J0bHkgYWZ0ZXIgdDIuDQo+ID4gPg0K PiA+ID4gTEVSLVoga25vd3MgYSBwcmlvcmkgdGhhdCBXaSA+IFdqLCBzbyBMRVItWiB0cmVhdHMg dGhpcyBhcyBhDQo+ID4gPiB1bmlkaXJlY3Rpb25hbCBsb2NraW5nIHByZWVtcHRpb24gY2FzZSwg YXMgaW4gc2VjdGlvbiAzLjMuMy4yIG9mIHRoZQ0KPiA+ID4gZHJhZnQuICBMRVItWiByZXNwb25k cyB0byB0aGUgU0YoV2ksMCkgd2l0aCBOUihXaSwwKS4gIFRoaXMgaXMgd2hhdA0KPiA+ID4gMy4z LjMuMiBkZXNjcmliZXMgYXMgTEVSLUEncyBiZWhhdmlvciBhdCB0MS4NCj4gPiA+DQo+ID4gPiBJ biB0aGlzIHdheSwgYm90aCBMRVItQSBhbmQgTEVSLVogY29udmVyZ2Ugb24gcHJvdGVjdGluZyBX aS4gIFNpbmNlDQo+IGl0DQo+ID4gaXMNCj4gPiA+IGxvY2tpbmcsIG5vIHRyYW5zbWlzc2lvbiBv ZiBwYWNrZXRzIHRha2VzIHBsYWNlIHNpbmNlIG5laXRoZXIgc2lkZQ0KPiBoYWQNCj4gPiA+IEFD S2QgdGhlIG90aGVyIHNpZGUncyBTRi4NCj4gPiA+DQo+ID4gPiBEb2VzIHRoYXQgcmVmbGVjdCB5 b3VyIHF1ZXN0aW9uLCBhbmQgZG9lcyBpdCBhbnN3ZXIgaXQ/DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+IGVyaWMNCj4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IEdyZWdvcnkgTWlyc2t5IFttYWlsdG86Z3JlZ29y eS5taXJza3lAZXJpY3Nzb24uY29tXQ0KPiA+ID4gPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjks IDIwMTIgMTo1MSBQTQ0KPiA+ID4gPiBUbzogRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7IHpoYW5n LmZlaTNAenRlLmNvbS5jbjsgWWFhY292DQo+ID4gV2VpbmdhcnRlbjsNCj4gPiA+ID4gbXBsc0Bp ZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSRTogQ29tbWVudHMgb24gZHJhZnQtZXp5LW1wbHMt MXRvbi1wcm90ZWN0aW9uLTAxDQo+ID4gPiA+DQo+ID4gPiA+IEhpIEVyaWMsDQo+ID4gPiA+IEJl bG93IGlzIHNjZW5hcmlvIHRoYXQgaW4gbXkgdmlldyB3b3VsZCBiZW5lZml0IGZyb20gYSB0aWVi cmVha2luZw0KPiA+ID4gcnVsZS4NCj4gPiA+ID4gV291bGQgYXBwcmVjaWF0ZSB5b3VyIGNvbnNp ZGVyYXRpb24gYW5kIGZlZWRiYWNrIHdoZXRoZXIgdGhpcyBpcw0KPiA+ID4gcmVhbGlzdGljDQo+ ID4gPiA+IGFuZCBub3QgYnJlYWtpbmcgUFNDOg0KPiA+ID4gPiAtIEFzc3VtZSB0aGF0IExTUCBQ IGlzIG5vdCBiZWluZyB1c2VkIG9yIHVzZWQgYnkgd29ya2luZyBwYXRoIG9mDQo+ID4gPiBwcmlv cml0eQ0KPiA+ID4gPiBOOw0KPiA+ID4gPiAtIExFUi1BIGRldGVjdHMgZmFpbHVyZSBvZiB3b3Jr aW5nIHBhdGggV2kgb2YgcHJpb3JpdHkgTSwgd2hlcmUgTQ0KPiA+DQo+ID4gTiwNCj4gPiA+ID4g TEVSLUEgc2VuZHMgU0YoMSwwKSB0byBMRVItWiBsaXN0aW5nIFdpIGFzIEZwYXRoOw0KPiA+ID4g PiAtIGFsbW9zdCBzaW11bHRlbmVvdXNseSwgYXQgbGVhc3QgYmVmb3JlIGl0IHJlY2VpdmVzIFNG IGZyb20NCj4gTEVSLUEsDQo+ID4gPiBMRVItWg0KPiA+ID4gPiBkZXRlY3RzIGZhaWx1cmUgb2Yg V2ogdGhhdCBoYXMgcHJpb3JpdHkgTS4gTEVSLVogc2VuZHMgU0YoMSwwKQ0KPiA+IGxpc3RpbmcN Cj4gPiA+IFdqDQo+ID4gPiA+IGFzIEZwYXRoOw0KPiA+ID4gPiAtIExFUi1aIHJlY2VpdmVzIFNG KDEsMCkgZnJvbSBMRVItQSBhbmQgc2luY2UgUHJpb3JpdHkoV2kpID09DQo+ID4gPiBQcmlvcml0 eShXaikNCj4gPiA+ID4gd291bGQgbm90IGNoYW5nZSB0byBwcm90ZWN0aW5nIFdpIHBhdGg7DQo+ ID4gPiA+IC0gTEVSLUEgcmVjZWl2ZXMgU0YoMSwwKSBmcm9tIExFUi1aIGFuZCBmb3IgdGhlIHNh bWUgcmVhc29uIHdvdWxkDQo+ID4ga2VlcA0KPiA+ID4gV2kNCj4gPiA+ID4gYXMgcGF0aCB0byBw cm90ZWN0Lg0KPiA+ID4gPiBJcyB0aGF0IHNlcXVlbmNlLCBzY2VuYXJpbyBjb3JyZWN0PyBXb3Vs ZCBMRVItQSBhbmQgTEVSLVogY29udmVyZ2UNCj4gPiBvbg0KPiA+ID4gPiBzZWxlY3Rpbmcgb25l IHBhdGggdGhleSdkIHByb3RlY3Q/DQo+ID4gPiA+DQo+ID4gPiA+ICAgIFJlZ2FyZHMsDQo+ID4g PiA+ICAgICAgICAgICAgR3JlZw0KPiA+ID4gPg0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBFcmljIE9zYm9ybmUgKGVvc2Jvcm5lKSBbbWFpbHRvOmVv c2Jvcm5lQGNpc2NvLmNvbV0NCj4gPiA+ID4gU2VudDogVGh1cnNkYXksIE1hcmNoIDI5LCAyMDEy IDQ6MzggQU0NCj4gPiA+ID4gVG86IEdyZWdvcnkgTWlyc2t5OyB6aGFuZy5mZWkzQHp0ZS5jb20u Y247IFlhYWNvdiBXZWluZ2FydGVuOw0KPiA+ID4gPiBtcGxzQGlldGYub3JnDQo+ID4gPiA+IFN1 YmplY3Q6IFJFOiBDb21tZW50cyBvbiBkcmFmdC1lenktbXBscy0xdG9uLXByb3RlY3Rpb24tMDEN Cj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBFTyMgIEkgd291bGQgYXJndWUgdGhhdCBvbmUg c2hvdWxkIG5vdCBoYXZlIExTUHMgb2YgdGhlICJzYW1lDQo+ID4gPiA+IHByaW9yaXR5Ii4NCj4g PiA+ID4gPiBUaGVyZSBtdXN0IGJlIGEgdGllYnJlYWtlciB0aGF0IGNhbiBoYW5kbGUgYWxsIHBv c3NpYmxlDQo+IGNvbmZsaWN0cywNCj4gPiA+IG5vDQo+ID4gPiA+ID4gbWF0dGVyIHdoYXQgb3Jk ZXIgb3IgaG93IG1hbnkgZmFpbHVyZXMuICBPbmNlIHRoZXJlIGlzIGENCj4gPiA+IGRldGVybWlu aXN0aWMNCj4gPiA+ID4gPiBtZWNoYW5pc20gZm9yIGFsbCBjYXNlcywgaXQgbWVhbnMgdGhhdCBh bGwgTFNQcyBhcmUgb2YgZGlmZmVyZW50DQo+ID4gPiA+IHByaW9yaXR5Lg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gR0lNPj4gVGllYnJlYWtpbmcgd291bGQgYmUgdXNlZCBvbmx5IGluIGNhc2Ugb2Yg c2ltdWx0ZW5lb3VzDQo+ID4gZmFpbHVyZQ0KPiA+ID4gPiBvZg0KPiA+ID4gPiA+IHR3byB3b3Jr aW5nIHBhdGhzIG9mIGVxdWFsIHByaW9yaXR5LiBPdGhlcndpc2UsIGVxdWFsIHByaW9yaXR5DQo+ ID4gd291bGQNCj4gPiA+ID4gbm90DQo+ID4gPiA+ID4gcHJlZW1wdCBvbmUgdGhhdCBpcyBhbHJl YWR5IGlzIHVzaW5nIHRoZSBwcm90ZWN0aW9uIHBhdGgsIGkuZS4NCj4gPiBGSUZPDQo+ID4gPiA+ IHdpbGwNCj4gPiA+ID4gPiBmdWxseSB3b3JrIGluIHRoaXMgY2FzZS4NCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID4gSSB0aGluayB0aGUgYmVoYXZpb3IgeW91IGRlc2NyaWJlIGlzIG1vcmUgYWJv dXQgU01QIHRoYW4gMTpuLiAgSW4NCj4gPiAxOm4NCj4gPiA+IHdlJ2QNCj4gPiA+ID4gYWx3YXlz IG1hZGUgdGhlIGFzc3VtcHRpb24gdGhhdCwgaW4gYSBnaXZlbiBwcm90ZWN0aW9uIGRvbWFpbiwN Cj4gb25seQ0KPiA+IGENCj4gPiA+ID4gc2luZ2xlIFcgY2FuIGJlIHByb3RlY3RlZCBhdCBhIHRp bWUuICBUbyBkbyBvdGhlcndpc2UgKHNheSwgVzEgYW5kDQo+ID4gVzINCj4gPiA+ID4gdXNpbmcg UCkgaXMgbm90IHBvc3NpYmxlIHVzaW5nIFBTQyBzaWduYWxpbmcgc2luY2Ugd2UgY2FuIG9ubHkN Cj4gPiA+IGluZGljYXRlIGENCj4gPiA+ID4gc2luZ2xlIExTUCBpbiB0aGUgRlBhdGggZmllbGQu DQo+ID4gPiA+DQo+ID4gPiA+IE5vdGhpbmcgcHJlY2x1ZGVzIG11bHRpcGxlIHByb3RlY3Rpb24g ZG9tYWlucyBmcm9tIHVzaW5nIHRoZSBzYW1lDQo+ID4gPiA+IHVuZGVybHlpbmcgbGluayBhbmQv b3Igc2FtZSBlbmRwb2ludHMsIGJ1dCB0aGF0J3MgYSBuZXR3b3JrIGRlc2lnbg0KPiA+ID4gPiBj b25zaWRlcmF0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g PiBlcmljDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG1wbHMgbWFpbGluZyBsaXN0DQo+ ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbXBscw0KPiANCj4gDQo+IDxodHRwOi8vdW1haWwuZXRyaS5yZS5rci9FeHRlcm5hbF9SZWFk Q2hlY2suYXNweD9lbWFpbD1lb3Nib3JuZUBjaXNjby5jb20mDQo+IG5hbWU9RXJpYytPc2Jvcm5l Kyhlb3Nib3JuZSkmZnJvbWVtYWlsPXJ5b29AZXRyaS5yZS5rciZtZXNzYWdlaWQ9JTNDMzQyMTM4 DQo+IDZjLTEzNWQtNDQ3NC1hZDQ0LTAxYmIzYmRjMTBiN0BldHJpLnJlLmtyJTNFPg0K From maarten.vissers@huawei.com Mon Apr 2 05:17:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3F21F8693 for ; Mon, 2 Apr 2012 05:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9owtBQKXlU0F for ; Mon, 2 Apr 2012 05:17:15 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2B81221F8796 for ; Mon, 2 Apr 2012 05:17:15 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW82161; Mon, 02 Apr 2012 08:17:14 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 05:15:18 -0700 Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 05:15:17 -0700 Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.01.0323.003; Mon, 2 Apr 2012 13:15:12 +0100 From: Maarten vissers To: "Eric Osborne (eosborne)" , Gregory Mirsky , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAcTRoAACTMqQ Date: Mon, 2 Apr 2012 12:14:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.112.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 12:17:16 -0000 Hi Eric, I see where I misunderstood you. "request" in protection switching context = is a reserved term for me. What you are looking for is the assignment of what is called "entity number= "s: W1, W2, W3, ..=20 These entity numbers are assigned by connection management (NMS or control = plane) when it sets up the protected connections. Both sides have to be con= figured with the same entity numbers, otherwise the APS protocol will fail.= =20 Because these entity numbers are present, one can re-use those numbers to e= xpress a priority order between Wi and Wj as specified in e.g. G.873.1. See= below: ----------------- [G.873.1] 8.10 Equal priority requests specifies the following: - In general, once a switch has been completed due to a request, it will not be overridden by another request of the same priority (first come, first served behaviour).=20 - When equal priority requests occur simultaneously, the conflict=20 is resolved in favour of the request with the lowest entity number.=20 # In bidirectional switching, a request received over the APS channel with a lower entity number will always override an identical priority local request with a higher entity number.=20 # Equal priority requests for the same entity number from both sides of a bidirectional protection group are both considered valid, and equivalent to a received "RR" from a near-end processing standpoint. ----------------- Regards, Maarten -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]=20 Sent: maandag 2 april 2012 12:57 To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingart= en; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 I'm not sure that answers my question, although it may be that it does and I don't understand it. I think what you're talking about is the alarm hierarchy; that is, if I get both LOP and FS on the same LSP, FS 'wins'. We have this behavior in 1:1 PSC already. What we're trying to sort out with 1:n is what happens when two LSPs encounter the same failure condition. If Wx and Wy both get SF, only one of them can be protected in 1:n. In order to decide which one we need something deterministic. Talking about 'priority' and 'tie-breakers' as if they were different makes no sense in this context. If two LSPs are of the same priority due to a priority config on a network device, the tie-breaker will be something else. As you and others have suggested, we can require the nodes to rely on the signaled FPath value, standardizing the fact that the lower value is alway of better priority. The question Greg originally raised was essentially "how do we know what that priority scheme is?" Our answer heretofore in the 1:n drafts has been "depends on the device, and both devices have to agree" but the more I look at it the more that doesn't make sense. I think what we need is something akin to what you pointed out earlier is already done in MSP; lower numeric value for FPath always wins. eric > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, April 02, 2012 6:06 AM > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Eric, >=20 > The standard specifies the priority order of requests. E.g. in G.873.1 > (OTN linear protection, > http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107= - > I!!PDF-E&type=3Ditems REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following specification is > included: >=20 > 8.3 Request type > The request types that may be reflected in the APS bytes are the > "standard" types traditionally supported by protection switching for SONET > and SDH. These requests reflect the highest priority condition, command, > or state (see Tables 2 and 3). In the case of unidirectional switching, > this is the highest priority value determined from the near end only. In > bidirectional switching, the local request will be indicated only in the > case where it is as high or higher than any request received from the far > end over the APS channel. In bidirectional switching, when the far end > request has the highest priority, the near end will signal Reverse > Request. > Table 2/G.873.1 - Request/state priorities with APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Signal Fail (SF) - protection 2 (see 8.9) > Forced Switch (FS) 3 > Signal Fail (SF) - working 4 > Signal Degrade (SD) 5 > Manual Switch (MS) 6 > Wait-to-Restore (WTR) 7 > Exercise (EXER) 8 > Reverse Request (RR) 9 > Do Not Revert (DNR) 10 > No Request (NR) 11 (lowest) > Table 3/G.873.1 - Request/state priorities without APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Forced Switch (FS) 2 > Signal Fail (SF) 3 > Signal Degrade (SD) 4 > Manual Switch (MS) 5 > Wait-to-Restore (WTR) 6 > Do Not Revert (DNR) 7 > No Request (NR) 8 (lowest) >=20 >=20 >=20 > Regards, > Maarten >=20 >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 11:56 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Maarten- >=20 > How does a node know that two requests are of equal priority? Is this > somehow configured a priori on the MSP endpoints? >=20 >=20 >=20 >=20 > eric >=20 >=20 > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Thursday, March 29, 2012 3:06 PM > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > protection): > > > > 8.10 Equal priority requests > > In general, once a switch has been completed due to a request, it will > not > > be overridden by another request of the same priority (first come, > first > > served behaviour). When equal priority requests occur simultaneously, > the > > conflict is resolved in favour of the request with the lowest entity > > number. In bidirectional switching, a request received over the APS > > channel with a lower entity number will always override an identical > > priority local request with a higher entity number. Equal priority > > requests for the same entity number from both sides of a bidirectional > > protection group are both considered valid, and equivalent to a > received > > "RR" from a near-end processing standpoint. > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Maarten vissers > > Sent: donderdag 29 maart 2012 14:54 > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > 1:n protection in a transport network at the path layer is not a very > > common protection switching application. This is due to the fact that > 1:n > > protection requires n+1 diverse routed paths. How many of those > diverse > > routed paths will be available in typical transport networks? Not > many... > > very often two diverse routed paths is all you can get... and this is > only > > truly guaranteed over time if the network domain is organized as > separate > > A and a B networks. Otherwise maintenance on the network may result in > > temporary rerouting of virtual links, resulting in routing W and P > > connections over the same fiber, node or duct. > > > > With n>2, separate networks can not be used and one has to find n+1 > > diverse routed paths through the network and guarantee that neither > > maintenance activities, nor network upgrades result in rerouting of > the > > virtual links so that W and P connections pass through the same fiber, > > node or duct. > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line card > > protection (end of 90's). > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Eric Osborne (eosborne) > > Sent: donderdag 29 maart 2012 14:31 > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > I still go back to my point that since only one W can ever use P, > there > > really is no such thing as 'equal priority'. We must have a priority > > scheme, whether it is the channel number in Fpath or whether it's some > > other mechanism, so that we know that Wi always beats Wj no matter > what > > order the events occur in. > > > > We had initially discussed leaving the exact priority scheme to the > > protection endpoints, but I see now that that may not work well across > > vendors. > > > > I think we have a few choices: > > > > 1) some sort of explicit priority field > > 2) define priority as the FPath value, lower is better (as Maarten > > points out, this is the current practice in SDH). > > > > Either one of these have costs to them. > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in > > locking mode means nobody is protected until both ends converge. This > > also makes things (potentially) very dynamic which is, I think, not > what > > we want in a protocol that has to converge in real time. > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > to > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > How > > often does this sort of thing happen in transport networks? Is it a > > real problem? > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 2:21 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > Hi Eric, > > > I agree with your logic and that current document handles scenario > you > > > present (prioties of simulteneously failed paths are different) > well. > > But > > > I still am concerned with case when priorities of Wi and Wj are > equal. > > If > > > you think that it might present a problem, then I see two possible > > ways to > > > address: > > > - disallow multiple LSPs being assigned equal priority (not the best > > way); > > > - define tiebreaking rule(s). > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 5:11 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Let me rewrite the messages a little bit in your example. Rather > than > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > LSPs > > in > > > question. And let's also say that the priority of Wi > Wj, just as > > you > > > have done. > > > > > > I also note that setting Path=3D=3D0 means you're using locking mode. > > This is > > > certainly a valid case, I just want to confirm that it's your > > intention? > > > > > > at t0, no failure. > > > > > > at t1, > > > LER-A sends SF(Wi,0) to LER-Z > > > AND > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > > > decided that Wi needs the protect channel. > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > t3, > > > shortly after t2. > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > unidirectional locking preemption case, as in section 3.3.3.2 of the > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. Since > it > > is > > > locking, no transmission of packets takes place since neither side > had > > > ACKd the other side's SF. > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Hi Eric, > > > > Below is scenario that in my view would benefit from a tiebreaking > > > rule. > > > > Would appreciate your consideration and feedback whether this is > > > realistic > > > > and not breaking PSC: > > > > - Assume that LSP P is not being used or used by working path of > > > priority > > > > N; > > > > - LER-A detects failure of working path Wi of priority M, where M > > > > N, > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > - almost simulteneously, at least before it receives SF from > LER-A, > > > LER-Z > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > listing > > > Wj > > > > as Fpath; > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > > > Priority(Wj) > > > > would not change to protecting Wi path; > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason would > > keep > > > Wi > > > > as path to protect. > > > > Is that sequence, scenario correct? Would LER-A and LER-Z converge > > on > > > > selecting one path they'd protect? > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > priority". > > > > > There must be a tiebreaker that can handle all possible > conflicts, > > > no > > > > > matter what order or how many failures. Once there is a > > > deterministic > > > > > mechanism for all cases, it means that all LSPs are of different > > > > priority. > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > failure > > > > of > > > > > two working paths of equal priority. Otherwise, equal priority > > would > > > > not > > > > > preempt one that is already is using the protection path, i.e. > > FIFO > > > > will > > > > > fully work in this case. > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. In > > 1:n > > > we'd > > > > always made the assumption that, in a given protection domain, > only > > a > > > > single W can be protected at a time. To do otherwise (say, W1 and > > W2 > > > > using P) is not possible using PSC signaling since we can only > > > indicate a > > > > single LSP in the FPath field. > > > > > > > > Nothing precludes multiple protection domains from using the same > > > > underlying link and/or same endpoints, but that's a network design > > > > consideration. > > > > > > > > > > > > > > > > > > > > eric > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls >=20 From wwwrun@rfc-editor.org Mon Apr 2 08:45:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDA821F8693 for ; Mon, 2 Apr 2012 08:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbsleZp1Fczc for ; Mon, 2 Apr 2012 08:45:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6785821F8683 for ; Mon, 2 Apr 2012 08:45:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2465372E01D; Mon, 2 Apr 2012 08:45:35 -0700 (PDT) To: awduche@uu.net, jmalcolm@uu.net, ja@uu.net, mo@uu.net, jmcmanus@uu.net, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20120402154535.2465372E01D@rfc-editor.org> Date: Mon, 2 Apr 2012 08:45:35 -0700 (PDT) Cc: mpls@ietf.org, nmalykh@gmail.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC2702 (3172) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:45:39 -0000 The following errata report has been submitted for RFC2702, "Requirements for Traffic Engineering Over MPLS". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2702&eid=3172 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh Section: 3.1 Original Text ------------- An induced MPLS graph consists of a set of LSRs which comprise the nodes of the graph and a set of LSPs which provide logical point to point connectivity between the LSRs, and hence serve as the links of the induced graph. it may be possible to construct hierarchical induced MPLS graphs based on the concept of label stacks (see [1]). Corrected Text -------------- An induced MPLS graph consists of a set of LSRs which comprise the nodes of the graph and a set of LSPs which provide logical point to point connectivity between the LSRs, and hence serve as the links of the induced graph. It may be possible to construct hierarchical induced MPLS graphs based on the concept of label stacks (see [1]). Notes ----- Typo Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2702 (draft-ietf-mpls-traffic-eng-01) -------------------------------------- Title : Requirements for Traffic Engineering Over MPLS Publication Date : September 1999 Author(s) : D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus Category : INFORMATIONAL Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From emily.chenying@huawei.com Mon Apr 2 13:45:47 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380B621F86BE for ; Mon, 2 Apr 2012 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Km9Rt48xLMk for ; Mon, 2 Apr 2012 13:45:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 88CB121F86CF for ; Mon, 2 Apr 2012 13:45:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP10552; Mon, 02 Apr 2012 16:45:46 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 13:44:00 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 13:44:01 -0700 Received: from SZXEML537-MBX.china.huawei.com ([169.254.1.146]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Tue, 3 Apr 2012 04:43:59 +0800 From: "Chenying (Emily)" To: IJsbrand Wijnands Thread-Topic: Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AQHNEKMHzQzVy2RitkKshuY+flYZW5aIAKKA Date: Mon, 2 Apr 2012 20:43:58 +0000 Message-ID: References: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> In-Reply-To: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:45:47 -0000 Dear Ice, Thanks for your comments. IMO, the mldp-via-p2p-tunnel and mldp-node-protec= tion mechanisms are under different situations. The following is my 2 cents= , please see whether this make sense to you. Thanks. The scalability issue would exist only when N node has a large number of do= wnstream routers. In mLDP deployment scenario, if users want to upgrade the= network into a mLDP capable one, such 'heavy-duty' N node should be the fi= rst priority for upgrade, because it really need packet duplication functio= nality. Once the N node is upgraded, then t-ldp is not needed, and there is= no scalability issue at all. But in mldp-node-protection scenario, such 'h= eavy-duty' N node should be the first priority for node protection, because= it is really important for the multicast tree. Then the t-ldp sessions are= always needed, and the scalability issue will always exist. This is why I = think the mldp-via-p2p-tunnel and mldp-node-protection mechanisms are under= different situations. Best regards, Emily Chen=20 -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 Sent: Monday, April 02, 2012 12:34 AM To: Chenying (Emily); Quintin zhao Cc: mpls@ietf.org Subject: Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2= p-tunnels-00 Dear Emily & Quintin, The solution in this draft requires a mLDP router upstream of the non-mLDP = router to do the packet forwarding and replication. The receiver interest i= s signaled to the upstream router via tLDP sessions. The upstream router wi= ll end up with the number of tLDP session to all the of the receivers downs= tream of the non-mLDP router, and will have to replicate the multicast pack= ets over P2P LSPs to them.je This has exactly the same tLDP scale considerations as discussed in the con= text of draft-wijnands-mpls-mldp-node-protection-00, yet for mLDP node prot= ection it seems to be a concern for you? Thx, Ice. BTW, we already have had a fair bit of discussion on the list Oct 2011 rega= rding the other concerns for this draft. From gregory.mirsky@ericsson.com Mon Apr 2 13:58:29 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70C21F85FD for ; Mon, 2 Apr 2012 13:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcXurnOXFXrr for ; Mon, 2 Apr 2012 13:58:28 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3355821F85F8 for ; Mon, 2 Apr 2012 13:58:01 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q32KvlSZ031383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Apr 2012 15:57:49 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 2 Apr 2012 16:57:46 -0400 From: Gregory Mirsky To: Maarten vissers , "Eric Osborne (eosborne)" , "zhang.fei3@zte.com.cn" , Yaacov Weingarten , "mpls@ietf.org" Date: Mon, 2 Apr 2012 16:57:46 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAcTRoAACTMqQABJbWpA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:58:30 -0000 Dear Maarten, Eric, et al., I think that "entity number" is good term to use from now in the discussion= . Would you agree? I think that the first bullet of the Maarten's quote is already present in = the discussed document. Now, IMHO, we need to select what represents entity= number and add appropriate description to case of simultaneous failure det= ection of two paths of equal priority. I think that Eric suggested to use F= path's index as entity number. I think it is good solution to my question. Regards, Greg -----Original Message----- From: Maarten vissers [mailto:maarten.vissers@huawei.com] Sent: Monday, April 02, 2012 5:15 AM To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov = Weingarten; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 Hi Eric, I see where I misunderstood you. "request" in protection switching context = is a reserved term for me. What you are looking for is the assignment of what is called "entity number= "s: W1, W2, W3, .. These entity numbers are assigned by connection management (NMS or control = plane) when it sets up the protected connections. Both sides have to be con= figured with the same entity numbers, otherwise the APS protocol will fail. Because these entity numbers are present, one can re-use those numbers to e= xpress a priority order between Wi and Wj as specified in e.g. G.873.1. See= below: ----------------- [G.873.1] 8.10 Equal priority requests specifies the following: - In general, once a switch has been completed due to a request, it will not be overridden by another request of the same priority (first come, first served behaviour). - When equal priority requests occur simultaneously, the conflict is resolved in favour of the request with the lowest entity number. # In bidirectional switching, a request received over the APS chann= el with a lower entity number will always override an identical prio= rity local request with a higher entity number. # Equal priority requests for the same entity number from both sides of a bidirectional protection group are both considered valid, and equivalent to a received "RR" from a near-end processi= ng standpoint. ----------------- Regards, Maarten -----Original Message----- From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] Sent: maandag 2 april 2012 12:57 To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingart= en; mpls@ietf.org Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 I'm not sure that answers my question, although it may be that it does and = I don't understand it. I think what you're talking about is the alarm hierarchy; that is, if I get= both LOP and FS on the same LSP, FS 'wins'. We have this behavior in 1:1 = PSC already. What we're trying to sort out with 1:n is what happens when t= wo LSPs encounter the same failure condition. If Wx and Wy both get SF, only one of them can be protected in 1:n. In ord= er to decide which one we need something deterministic. Talking about 'pri= ority' and 'tie-breakers' as if they were different makes no sense in this = context. If two LSPs are of the same priority due to a priority config on = a network device, the tie-breaker will be something else. As you and other= s have suggested, we can require the nodes to rely on the signaled FPath va= lue, standardizing the fact that the lower value is alway of better priorit= y. The question Greg originally raised was essentially "how do we know what th= at priority scheme is?" Our answer heretofore in the 1:n drafts has been "= depends on the device, and both devices have to agree" but the more I look = at it the more that doesn't make sense. I think what we need is something akin to what you pointed out earlier is a= lready done in MSP; lower numeric value for FPath always wins. eric > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, April 02, 2012 6:06 AM > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > Hi Eric, > > The standard specifies the priority order of requests. E.g. in G.873.1 > (OTN linear protection, > http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107= - > I!!PDF-E&type=3Ditems REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following specification is > included: > > 8.3 Request type > The request types that may be reflected in the APS bytes are the > "standard" types traditionally supported by protection switching for SONET > and SDH. These requests reflect the highest priority condition, command, > or state (see Tables 2 and 3). In the case of unidirectional switching, > this is the highest priority value determined from the near end only. In > bidirectional switching, the local request will be indicated only in the > case where it is as high or higher than any request received from the far > end over the APS channel. In bidirectional switching, when the far end > request has the highest priority, the near end will signal Reverse > Request. > Table 2/G.873.1 - Request/state priorities with APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Signal Fail (SF) - protection 2 (see 8.9) > Forced Switch (FS) 3 > Signal Fail (SF) - working 4 > Signal Degrade (SD) 5 > Manual Switch (MS) 6 > Wait-to-Restore (WTR) 7 > Exercise (EXER) 8 > Reverse Request (RR) 9 > Do Not Revert (DNR) 10 > No Request (NR) 11 (lowest) > Table 3/G.873.1 - Request/state priorities without APS protocol > Request/state Priority > Lockout for Protection (LoP) 1 (highest) > Forced Switch (FS) 2 > Signal Fail (SF) 3 > Signal Degrade (SD) 4 > Manual Switch (MS) 5 > Wait-to-Restore (WTR) 6 > Do Not Revert (DNR) 7 > No Request (NR) 8 (lowest) > > > > Regards, > Maarten > > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 11:56 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > Hi Maarten- > > How does a node know that two requests are of equal priority? Is this > somehow configured a priori on the MSP endpoints? > > > > > eric > > > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Thursday, March 29, 2012 3:06 PM > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > protection): > > > > 8.10 Equal priority requests > > In general, once a switch has been completed due to a request, it will > not > > be overridden by another request of the same priority (first come, > first > > served behaviour). When equal priority requests occur simultaneously, > the > > conflict is resolved in favour of the request with the lowest entity > > number. In bidirectional switching, a request received over the APS > > channel with a lower entity number will always override an identical > > priority local request with a higher entity number. Equal priority > > requests for the same entity number from both sides of a bidirectional > > protection group are both considered valid, and equivalent to a > received > > "RR" from a near-end processing standpoint. > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Maarten vissers > > Sent: donderdag 29 maart 2012 14:54 > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > 1:n protection in a transport network at the path layer is not a very > > common protection switching application. This is due to the fact that > 1:n > > protection requires n+1 diverse routed paths. How many of those > diverse > > routed paths will be available in typical transport networks? Not > many... > > very often two diverse routed paths is all you can get... and this is > only > > truly guaranteed over time if the network domain is organized as > separate > > A and a B networks. Otherwise maintenance on the network may result in > > temporary rerouting of virtual links, resulting in routing W and P > > connections over the same fiber, node or duct. > > > > With n>2, separate networks can not be used and one has to find n+1 > > diverse routed paths through the network and guarantee that neither > > maintenance activities, nor network upgrades result in rerouting of > the > > virtual links so that W and P connections pass through the same fiber, > > node or duct. > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line card > > protection (end of 90's). > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Eric Osborne (eosborne) > > Sent: donderdag 29 maart 2012 14:31 > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > I still go back to my point that since only one W can ever use P, > there > > really is no such thing as 'equal priority'. We must have a priority > > scheme, whether it is the channel number in Fpath or whether it's some > > other mechanism, so that we know that Wi always beats Wj no matter > what > > order the events occur in. > > > > We had initially discussed leaving the exact priority scheme to the > > protection endpoints, but I see now that that may not work well across > > vendors. > > > > I think we have a few choices: > > > > 1) some sort of explicit priority field > > 2) define priority as the FPath value, lower is better (as Maarten > > points out, this is the current practice in SDH). > > > > Either one of these have costs to them. > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and in > > locking mode means nobody is protected until both ends converge. This > > also makes things (potentially) very dynamic which is, I think, not > what > > we want in a protocol that has to converge in real time. > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > to > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > How > > often does this sort of thing happen in transport networks? Is it a > > real problem? > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > Sent: Thursday, March 29, 2012 2:21 PM > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > Hi Eric, > > > I agree with your logic and that current document handles scenario > you > > > present (prioties of simulteneously failed paths are different) > well. > > But > > > I still am concerned with case when priorities of Wi and Wj are > equal. > > If > > > you think that it might present a problem, then I see two possible > > ways to > > > address: > > > - disallow multiple LSPs being assigned equal priority (not the best > > way); > > > - define tiebreaking rule(s). > > > > > > Regards, > > > Greg > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: Thursday, March 29, 2012 5:11 AM > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Let me rewrite the messages a little bit in your example. Rather > than > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > LSPs > > in > > > question. And let's also say that the priority of Wi > Wj, just as > > you > > > have done. > > > > > > I also note that setting Path=3D=3D0 means you're using locking mode. > > This is > > > certainly a valid case, I just want to confirm that it's your > > intention? > > > > > > at t0, no failure. > > > > > > at t1, > > > LER-A sends SF(Wi,0) to LER-Z > > > AND > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has already > > > decided that Wi needs the protect channel. > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > t3, > > > shortly after t2. > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > unidirectional locking preemption case, as in section 3.3.3.2 of the > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is what > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. Since > it > > is > > > locking, no transmission of packets takes place since neither side > had > > > ACKd the other side's SF. > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Hi Eric, > > > > Below is scenario that in my view would benefit from a tiebreaking > > > rule. > > > > Would appreciate your consideration and feedback whether this is > > > realistic > > > > and not breaking PSC: > > > > - Assume that LSP P is not being used or used by working path of > > > priority > > > > N; > > > > - LER-A detects failure of working path Wi of priority M, where M > > > > N, > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > - almost simulteneously, at least before it receives SF from > LER-A, > > > LER-Z > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > listing > > > Wj > > > > as Fpath; > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > > > Priority(Wj) > > > > would not change to protecting Wi path; > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason would > > keep > > > Wi > > > > as path to protect. > > > > Is that sequence, scenario correct? Would LER-A and LER-Z converge > > on > > > > selecting one path they'd protect? > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > priority". > > > > > There must be a tiebreaker that can handle all possible > conflicts, > > > no > > > > > matter what order or how many failures. Once there is a > > > deterministic > > > > > mechanism for all cases, it means that all LSPs are of different > > > > priority. > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > failure > > > > of > > > > > two working paths of equal priority. Otherwise, equal priority > > would > > > > not > > > > > preempt one that is already is using the protection path, i.e. > > FIFO > > > > will > > > > > fully work in this case. > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. In > > 1:n > > > we'd > > > > always made the assumption that, in a given protection domain, > only > > a > > > > single W can be protected at a time. To do otherwise (say, W1 and > > W2 > > > > using P) is not possible using PSC signaling since we can only > > > indicate a > > > > single LSP in the FPath field. > > > > > > > > Nothing precludes multiple protection domains from using the same > > > > underlying link and/or same endpoints, but that's a network design > > > > consideration. > > > > > > > > > > > > > > > > > > > > eric > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > From mustapha.aissaoui@alcatel-lucent.com Mon Apr 2 20:20:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EA021F8753 for ; Mon, 2 Apr 2012 20:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0WVjka4uirj for ; Mon, 2 Apr 2012 20:20:23 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DC21F86F4 for ; Mon, 2 Apr 2012 20:20:23 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q333KH3G001742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Apr 2012 22:20:18 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q333KHRn008332 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Apr 2012 22:20:17 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Mon, 2 Apr 2012 22:20:17 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" Date: Mon, 2 Apr 2012 22:20:15 -0500 Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3gBWT9Fg Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5A09189@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "mpls@ietf.org" Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 03:20:26 -0000 Hi Rajiv, Could you provide in details how you believe the presence of duplicate link= -local addresses from two neighbouring LSRs can cause blackhole of traffic? What you describe in Section 8 is already how implementations of RFC 5036 o= perate. Before you can resolve a FEC to a link, you have to find out the ou= tgoing interface and next-hop of that FEC prefix in the routing table. Then= you need to find the LSR-id which advertised that next-hop address as its = local address and that there is a hello adjacency to that LSR-id over that = interface. In the case of a dual-stack inteface, you just need to find a li= nk Hello adjacency over that interface, it does not have to be an IPv6 adja= cency, to resolve an IPv6 FEC. Because LDP follows routing, you cannot blackhole traffic when overalpping = link-local addresses exist to different LDP peers over two different interf= aces or subnets. If overlapping occurs over the same subnet, then neighbour= discovery will detect it and will shutdown IPv6 forwarding over that inter= face. Again, there is no relationship of FEC resolution to a link and the type of= the control plane adjacency. You just need to have an adjacency. Regards, Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Sunday, April 01, 2012 6:20 AM To: Shah, Himanshu Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-iet= f-mpls-ldp-ipv6-06) Hi Himanshu, Appreciate your question. There are at least two benefits for sending IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack = interface if enabled with both LDP IPv4 and LDP IPv6: 1. Discovering v4 or/and v6 transport that the peer is willing to use for b= ootstrapping the subsequent TCP session (and resorting to using the alterna= te transport if the preferred one failed) Similar to that of happy eyeball (unless hardcoded or got into coll= ision)! 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as th= e routing next-hops Please see section 8 for more details http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 While it may be tempting to maintain only one hello adj (IPv4, say) (that g= ot used to establish the subsequent (IPv4, say) TCP/LDP session) and let go= of the other hello adj (IPv6, say) that didn't get used, it could cause tr= affic blackholing (due to missing #2 above) for packets going on LSPv6. Does this clarify? Cheers, Rajiv > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Wednesday, March 28, 2012 4:06 PM > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > I second the same concern and fail to understand the rationale to bypass the > available > tool (capacity negotiation). > Thanks, > himanshu > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Aissaoui, Mustapha (Mustapha) > Sent: Wednesday, March 28, 2012 3:56 PM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Rajiv, > I am afraid we are not making progress on the technical questions I raised on > this draft. > > For the benefit of everyone else on the mailing list, I am going to state the > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. This > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) which can be > resolved in the datapath over a given link based on the type of the control > plane adjacency (IPv4 or IPv6) established over that link. This coupling of FEC > resolution to the type of control plane adjacency is not correct and breaks so > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC type between > peers is independent of the adjacency established. > > In addition, this proposal now means that we need 2 link Hello adjacencies over > each link and 2 targeted Hello adjacencies between any two LSR nodes. This is > not good from a scaling perspective while it provides no gain. > > In an earlier exchange on this thread, we discussed the need for introducing > per Hello adjacency capability negotiation to address the probem of which FEC > types can be resolved over a given link adjacency. That is the correct approach > to the problem and we should keep the behaviour of RFC 5036 as is, that is an > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an IPv6 link > adjacency will bootstrap an IPv6 LDP session. There is no need or value for two > link Hellos associating with the same IPv4 or IPv6 LDP session. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Monday, March 12, 2012 12:25 PM > To: Aissaoui, Mustapha (Mustapha) > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > Hi Mustapha, > > Thanks for the discussion. Please see inline, > > 1. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > > 2. > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. > > It is not about the FEC. It is about the LSP, and rightfully so. > > Hopefully, answering this Q will help us - If there are 3 links (LDP > enabled) between two LSRs and only two have hello adj leading to the working > LDP session, then would the LSRs use the 3rd link (which doesn't have valid > hello adj) for MPLS packet forwarding? > > - If your answer is Yes, then we have a fundamental disagreement independent > of LDP IPv6. > - If the answer is No, then that's inline with what's described in the last para of > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > Perhaps, the text needs a bit of rephrasing, so please feel free to suggest. > > The above has no bearing on FEC type e.g. IPv4 packet being sent over > LSPv6 or vice versa. > > Hence, we leave the text as-it-is. > > > 3. > > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. > > Removing last paragraph of section 2.5.2 from RFC 5036 ? > > That would fundamentally break RFC5036. > > > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. > > Correct and that's because each LSR uses the same LDP Identifier and qualifies > for the point 1 of section 2.5.2 in RFC5036, which suggests to not establish a > new session if there is already one existing using the same LDP Identifier: > > // > 1. If LSR1 does not already have an LDP session for the exchange > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP // > > > > It becomes an issue of association of multiple Hello adjacencies with > > a single TCP connection. > > And it is not an issue thanks to the last para of section 2.5.2. We can NOT afford > to remove it. > > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. > > > 4. > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. > > That's incorrect. As you know, PW-FEC, as per RFC5036, already requires > 'extended/targetted hello adj', not 'basic hello adj' with the peer before > exchanging PW-FECs with that peer. > > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 is > enabled on an interface. This is already implicit in RFC5036. > And if the interface is a dual-stack interface, then the behavior shouldn't > change. > > > 5. > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. > > Well, RFC5036 (LDP version 1) prescribes using a single session for exchanging > FEC-label bindings for various FEC types. > > We could work on version 2 to move away from that intention e.g. allow using > more than one session between two LSRs. > > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. > > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > exchanged, as permitted. > We are in agreement here. > > 6. > Given the lack of response for #6, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > 7. > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > > Please see my response to #4. Nonetheless, this is moot, as it is a MAY, and is > local to the LSR. > FWIW, this point has been beaten to death last yr, and I would urge you to > check the discussion on the mailing list from last yr. > > 8. > > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? > > If the node still receives the unsupported FEC or address type, then it indicates > that the peer has a bug, and it should follow the behavior specified in RFC5036 > e.g. declare a fatal error. > > This is orthogonal to capability or FEC filter, since the assumption here is that > an LSR is willing to send/receive FEC-label bindings for both IPv4 and IPv6 and > more. The point is that the loophole that has existed all along is closed when an > LSR gets upgraded with the code compliant with this specification. > > 9. > Given the lack of response for #1, I am assuming this we have agreed and > closed the discussion on this point. Thanks. > > 10. > > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. > > You do make a good point about us not changing the LDP protocol version, so, it > is not a new protocol, and I agree. > I will consider to change GTSM to optional (MAY), subjected to Carlos's opinion. > > We will revisit it if/when the consensus suggests otherwise prior to RFC > publication. > We can close this point as well. > > Cheers, > Rajiv > > > -----Original Message----- > > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Friday, March 02, 2012 1:09 AM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > See some follow-up inline. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Wednesday, February 29, 2012 10:28 PM > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the review of the document and the feedback. It is never > too late. > > :) Sorry about the delay in getting back to you. > > > > Please see inline, > > > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > Yes, they were discussed in the past and closed. > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > No. > > > > While it is a common practice to assign a host route to the loopback > interface, > > and it is a common practice to use loopback interface as the next-hop, > we > > must not assume the common practice to be the norm for the protocol. > In > > fact, there is NO technical argument against using the non-host route > on a > > loopback interface. > > > > In fact, almost every implementation allows the next-hop to be a > non-host > > route, and I am aware of at least one implementation that allows LDP > to > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that if > hello adj > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > forwarding on that interface. So, if IPv6 hello adj failed, then stop > the IPv6 > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > blindly > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > // > > when it receives a Hello that matches the adjacency. If the timer > > expires without receipt of a matching Hello from the peer, LDP > > concludes that the peer no longer wishes to label switch using that > > label space for that link (or target, in the case of Targeted > Hellos) > > or that the peer has failed. The LSR then deletes the Hello // > > > > MA> Not really. The "matching" has nothing to do with the type of FEC. > It has > > to do with the parameters of the adjacency (LSRid, label space) over > that link. > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > > I agree. It doesn't have anything to do with the address family, but > it > > becomes restrictive when having to accommodate transport of two > different > > address families (IPv4 and IPv6). Pls see more details on this later > on. > > > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > That's not correct (and the implementation is in violation of > RFC5036). > > > > We had good discussion on this early on. In fact, we had an editor's > note on > > this in initial versions of this document to solicit discussion on > that. > > > > The last para of section 2.5.2, as stated, would result in a > particular IP address > > (1.1.1.1, say) being encoded in the transport address in both > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > (which is > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > from > > carrying IPv6 transport address (or IPv4 hello from carrying > > IPv4 transport address). It would not make sense. > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > address > > and vice versa. It wouldn't make sense and would be incorrect. > > > > That's why the change was needed. > > > > MA> When parallel links exist between two LSRs, the TCP connection is > > bootstrapped by one of the hello adjacencies. An implementation > compliant > > to RFC 5036 will not accept two TCP connections between the same two > LSRs > > and thus the fact that the transport addresses exchanged are different > has > > no impact. In fact take the simple case of a link LDP and a T-LDP > sessions for > > directly connected LSRs. The T-LDP can use a loopback address as the > > transport address while the link LDP can use the link address as the > transport > > address and they will both share the same TCP connection which was > > bootstrapped first. It becomes an issue of association of multiple > Hello > > adjacencies with a single TCP connection. That is why I am saying the > last > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > We thought so too, but we uncovered various corner cases in which this > > becomes problematic, not to mention that the indeterminism it would > bring > > into the picture. The easiest was to maintain hello adj per > address-family per > > peer. > > > > For ex, consider three LDP enabled interfaces between R1 and R2, where > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > maintain only > > single adj, then they would have hello adj of one transport (v6, say) > on dual- > > stack interfaces, and another transport (v4, > > say) on 3rd interface. > > > > Hello adj is tightly coupled with the functional LDP peering. If (the > > last) hello adj is lost, then LDP peering must be brought down. > > Additionally, if hello adj is gone from an interface, then LDP should > prohibit > > MPLS forwarding from using that interface. > > > > Another way to think about it is - if IPv4 stops functioning on an > interface, but > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > penalized. > > And vice versa. > > > > Having separate hello adj maintenance is much cleaner/simpler and > provides > > deterministic behavior. > > > > Nonetheless, an implementation could choose to optimize, if needed, to > > keep both address-family related info in a single adjacency structure, > but this > > is all implementation specific. :) > > > > MA> The proper way to handle this is to implement separate LDP > sessions > > not separate Hello adjacencies sharing the same LDP session. Current > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > exchanges and they do not require separate hello adjacencies. These > are just > > FEC types and have no relationship whatsoever to the type of > adjacency. > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > Good point, but this is a different problem. It is not about the > sequence > > (which was ok if IPv4 hellow as carrying two IPv4 transport > addresses). > > > > The problem is that allowing IPv4 based "discovery" to suggest an IPv6 > > transport address is fundamentally a wrong approach, IMO. How would > IPv4 > > know that IPv6 transport is even functional (and vice versa). IPv4 > based > > discovery should suggest IPv4 transport, and IPv6 based discovery > should > > suggest IPv6 transport. > > > > MA> Again, what you are asking for can be solved with the use of > separate > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not a > protocol > > design decision. BGP allows the exchage of IPv4 prefixes over an IPv6 > > connection and vice-versa. There is no relationship whatsoever between > the > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > We need the address-family awareness in peer hello adjacency/s, > whether it > > is a kept in a single adj structure or not. > > > > Loosing the AFI awareness leads up the other problems that I mentioned > > earlier. > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > It is MAY. :) > > It was changed to MAY based on the exhaustive discussion on mailing > list in > > 2011 for us to move forward. > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is a > > different protocol. > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > We initially thought so too, until we discovered the following very > explicitly in > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > // > > Section 3.5.5.1 - > > If an LSR does not support the Address Family specified in the Address > List > > TLV, it SHOULD send an Unsupported Address Family Notification to its > LDP > > signaling an error and abort processing the message. > > > > Section 3.4.1.1 - > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address > > Family it does not support, it SHOULD stop decoding the FEC TLV, abort > > processing the message containing the TLV, and send an "Unsupported > > Address Family" Notification message to its LDP peer signaling an > error. > > // > > > > MA> Well all this is controlled via the LDP capability or configuring > the FEC > > filters. If after this, the node still receives the unsupported FEC or > address > > type, what else do you suggest it should do? > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > Because it is native in IPv6 to allow for link-local addresses that > IPv4 never > > allowed. > > So, what was an anomaly with IPv4 is now a standard behavior with > IPv6, > > hence, that verbiage. > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > We posed the Q about GTSM being the default or not during IETF 80, and > > there were 10-yes and 0-no (mostly from operators) Pls see the > minutes, > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > MA> Well that certainly contradicts the process. If you are creating a > new LDP > > version protocol, we can consider making it mandatory by default. If > you > > claim you are still compliant to RFC 5036 then you cannot change it > and it > > must remain optional. > > > > Cheers, > > Rajiv > > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Aissaoui, Mustapha (Mustapha) > > > Sent: Monday, February 06, 2012 3:21 PM > > > To: Shane Amante > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Shane, > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > LDP > > session > > > from a peer which is identified by the LDP identifier tuple {LSR-id, > > label-space- > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > different label > > > spaces, then they must use two different Hello adjacencies and LDP > > sessions for > > > that. Also, if an implementation supports virtualization of LDP, > then > > a different > > > LDP identifier altogether can be used to establish a separate LDP > > session. Other > > > than that, there is no relation between the type of adjacency and > the > > FEC which > > > are carried. For example, the same LDP Hello Adjacency and LDP > session > > are > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > between > > two > > > directly connected peers. > > > > > > As far as I know BGP is not very different. It offers the ability to > > carry IPv4 NLRI > > > over a IPv6 session and vice versa. > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > IPv4 > > on an IPv4 > > > session between two LSRs, then we should consider extending RFC > 5036 > > to > > > allow for two different LSR-id values sharing the same global label > > space. This > > > way, we can have separate Hello adjacency and LDP session and it is > up > > to the > > > user to assign which FEC type is allowed on which LDP session. This > is > > a new > > > work item but in my view much cleaner and backward compatible with > RFC > > > 5036 than to try to tie the address family to the type of Hello > > adjacency. > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > Hello > > > adjacency but a single shared LDP session. It is not exactly what > you > > are asking > > > for. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > Sent: Friday, February 03, 2012 11:32 PM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Mustapha, > > > > > > I am not an author, but I do want to provide some operational input > on > > some of > > > your comments. Specifically, I get the sense from several of your > > comments -- > > > actually, moreso from #3 -- that you are opposed to maintaining > > separate LDP > > > Hello and/or Session Adjacencies: 1 for each address family. (If my > > impression > > > is incorrect I apologize). > > > > > > I actually *do* want to have separate LDP Hello and Session > > adjacencies: one > > > per address family, at least at this point in time. I'm concerned > > about > > > [operational] issues that may develop in, for example, v6 affecting > > the > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > one > > more > > > concrete example, 6man/v6ops are only right now working on improving > > the > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > areas where > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > problems in v6 > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > FWIW, there has > > > already been a precedent here wrt BGP where there it maintains > > separate > > > neighbors/sessions for each address family, so why aren't we doing > the > > same > > > thing for LDP? > > > > > > Ultimately, having separate sessions over-the-wire is much more > > intuitive to > > > operators in lots of cases where they may expect that a > configuration > > change > > > or bugs they /think/ are only going to affect one address family, > > really do only > > > affect one address family. Besides, LDP Hello & Sessions timers, > when > > set to > > > default, are extremely relaxed (order of several seconds), so the > > burden on > > > implementations to maintain separate sessions should be miniscule. > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > over the > > > wire to avoid "fate sharing". Only when an operator chooses to > > explicitly > > > configure their device to have hellos and sessions share fate should > > the device > > > do so. > > > > > > Just my $0.02, > > > > > > -shane > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > Dear authors, > > > > below are comments on this draft. I realize this draft passed WG > > last call but I > > > think the issues are significant enough in my view. I apologize if > > some of these > > > comments were already raised on this mailing list. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is referring > > to a > > > loopback interface of the egress router, not any other interface. > That > > is why > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > explicitly refer to > > > /128 for IPv6. > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > " > > > > Additionally, it is desirable that a packet is forwarded to an LSP > > of an egress > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > with that of > > > the LDP hello adjacency on the next-hop interface. > > > > " > > > > MA> RFC 5036 makes no tie, and there should not be, between the > type > > of > > > resolved FEC and the adjacency to the next-hop. I think this > statement > > should be > > > removed. > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > " > > > > This document qualifies the first sentence of last paragraph of > > > > Section 2.5.2 of [RFC5036] to be per address family and > therefore > > > > updates that sentence to the following: "For a given address > > family > > > > over which a Hello is sent, and a given label space, an LSR MUST > > > > advertise the same transport address." This rightly enables the > > per- > > > > platform label space to be shared between IPv4 and IPv6. > > > > " > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > has > > anything > > > to do with the address family. It only requires that an LSR > advertises > > the same > > > transport address in all Hello adjacencies that advertise the same > > label space. > > > In fact the intent as explained in the second sentence of that same > > paragraph > > > was to make sure that if two LSRs are establishing multiple Hello > > adjacencies > > > that they play the same active/passive role for establishing the TCP > > connection. > > > > > > > > In practice though, most implementations allow Hello adjacencies > > over > > > parallel links with different IPv4 transport addresses and it works > > just fine. I > > > think we should remove this restriction from RFC 5036 and not refer > to > > it in this > > > draft. > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > messages > > over a > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs on > > the same > > > subnet. However, this does not justify the need to maintain two > > separate Hello > > > ajacencies per peer. In practice, each router can send both IPv4 and > > IPv6 hellos > > > but only a single Hello adjacency must be allowed with each peer > > (LSR-id, label- > > > space} over a given interface, whichever came up first. Over a P2P > > interface, it > > > is up to the user to configure which adjacency they want to form > which > > means > > > there is only a need to send one type of hello. > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > 2. An LSR SHOULD accept the Hello message that contains both IPv4 > > > > and IPv6 transport address optional objects, but MUST use > > only > > > > the transport address whose address family is the same as > > that > > > > of the IP packet carrying Hello. > > > > " > > > > MA> This is not a new issue. If I am not mistaken, this can also > > occur in RFC > > > 5036 implementations if an LSR receives two optional IPv4 transport > > address > > > TLVs. RFC 506 does not say what to do with this and was left for > > > implementations to handle. If we absolutely need to specify > something, > > maybe > > > we should say only the first TLV in the Hello message is processed. > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if it has both IPv4 and IPv6 > > > > hello adjacencies for the same LDP Identifier (over a dual- > > > > stack interface, or two or more single-stack IPv4 and IPv6 > > > > interfaces). This applies to the section 2.5.2 of RFC5036. > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a new > > > > LDP session with a remote LSR, if they attempted two TCP > > > > connections using IPv4 and IPv6 transport addresses > > > > simultaneously. > > > > " > > > > MA> No need for all this if you enforce that only a single > adjacency > > is > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > " > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings (as > > > > well as interface addresses via ADDRESS message) from/to the > peer > > > > over an LDP session (using whatever transport), unless it has > > valid > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > section 6.2. > > > > " > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > bindings > > should > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > narrow > > > interpretation of RFC 5036. > > > > The proper solution to this is to add an IPV6 LDP capability to > > negotiate which > > > FEC address family can be exchanged regardless if the Hello > adjacency > > is IPv4 > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > " > > > > Additionally, to ensure backward compatibility (and > interoperability > > > > with IPv4-only LDP implementations), this document specifies that > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > containing FEC Elements of different address-family. In other words, > a > > FEC TLV > > > in the label mapping message MUST contain the FEC Elements belonging > > to the > > > same address-family. > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > message) with an Address List TLV containing IP addresses of > different > > address- > > > family. In other words, an Address List TLV in the Address (or > Address > > > Withdraw) message MUST contain the addresses belonging to the same > > > address-family.. > > > > " > > > > MA> This is yet another narrow interpretation of RFC 5036. There > is > > no > > > justification for such a restriction and certainly RFC 5036 does not > > make it. A > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > Element has > > > its own Type, Length, Value and is self sufficient. Although > > implementations > > > don't mix and match FEC elements but they are designed to handle it. > > Same > > > applies to Address list TLV. > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > MA> I believe the need to handle duplicate interface addresses > > received from > > > two different peers is not a new issue. It needed to be handled in > > existing IPv4 > > > based LDP implementations. Maybe the authors can specify why > duplicate > > link > > > local addresses is any different. > > > > > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > This document also specifies that the LDP/TCP transport connection > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > Security > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an LDP > > > > session peering established between the adjacent LSRs using > Basic > > > > Discovery, by default. > > > > " > > > > MA> GTSM must be optional as explained in RFC 5082. This draft is > > not > > > defining a new protocol and as such it should remain optional as in > > RFC 5036. > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > =3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From muly_i@rad.com Tue Apr 3 01:21:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1721F849B for ; Tue, 3 Apr 2012 01:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7hVZlsclKWm for ; Tue, 3 Apr 2012 01:21:11 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9075221F8497 for ; Tue, 3 Apr 2012 01:21:06 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 3 Apr 2012 11:11:09 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 3 Apr 2012 11:21:01 +0300 From: Muly Ilan To: Venkatesan Mahalingam Thread-Topic: Comments to draft-ietf-mpls-tp-te-mib-02 Thread-Index: Ac0QJYUMmCdCsfNGRk2i+tu+4OdVzABHdXmAAAvS1gA= Date: Tue, 3 Apr 2012 08:21:01 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87041799FF@EXRAD5.ad.rad.co.il> References: <32CB7A1F0806AB4688CE3F22C29DAC8704179617@EXRAD5.ad.rad.co.il> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC87041799FFEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090205.4F7AB2EF.0022,ss=1,fgs=0 Cc: "mpls@ietf.org" , "thomas.nadeau@ca.com" Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-te-mib-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:21:22 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87041799FFEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good. Thanks, Muly From: Venkatesan Mahalingam [mailto:venkat.mahalingams@gmail.com] Sent: Tuesday, April 03, 2012 8:42 AM To: Muly Ilan Cc: Kannan.Sampath@aricent.com; thomas.nadeau@ca.com; aldrin.ietf@gmail.com= ; mpls@ietf.org Subject: Re: Comments to draft-ietf-mpls-tp-te-mib-02 Muly Ilan, Hi Sorry for the delayed response. Thanks for the comments. Please find below the reply tagged [VM]. Regards, Venkat. On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan > wrote: Hi, I have 2 comments to draft-ietf-tp-te-mib-02: 1. In mplsXCExtTable - suggest to make the mplsXCExtTunnelPointer a r= ead-only object. The NE can automatically fill in this backward pointer val= ue when the manager sets the mplsTunnelXCPointer in the mplsTunnelTable. Th= is will be similar to the existing backward pointers mplsInSegmentXCIndex &= mplsOutSegmentXCIndex. [VM] Yes, we will consider this change in our next version. 2. In mplsTunnelExtTable - suggest to add a columnar object mplsTunne= lExtRemoteTunnelIndex. This will hold the index of the bidirectional tunnel= at the egress LSR. To support LSP connectivity verification per RFC6428, d= etection of mis-connectivity defect, the (global-id, node-id, tunnel-num an= d lsp-num) should be known at both ends. The global-id and node-id of the r= emote LSR are available from mplsNodeConfigTable. Assuming co-routed LSPs, = the lsp-num is given by mplsXCLspId. The only missing identifier is the rem= ote tunnel-num since per RFC6370 each end can have its own tunnel number. [VM] Yes, your suggestion is exactly matching with our next version update.= Please find below the expected additional MIB objects for mplsTunnelExtTab= le, 1. mplsTunnelExtDestTnlIndex 2. mplsTunnelExtDestTnlInstance 3. mplsTunnelExtDestTnlValid - TRUE/FALSE TRUE will be set if MIB objects mplsTunnelExtDestTnlIndex and mplsTu= nnelExtDestTnlInstance are used for destionation tunnel indentification, FA= LSE will be set otherwise. 4. mplsTunnelExtOppositeDirTnlValid - TRUE/FALSE TRUE will be set if MIB object mplsTunnelOppositeDirPtr is used for de= stination tunnel identifiction, FALSE will be set otherwise. Regards, Muly Ilan Senior System Architect, R&D T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930 | muly_i@rad= .com RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, Israe= l | www.rad.com --_000_32CB7A1F0806AB4688CE3F22C29DAC87041799FFEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Looks good.

 <= /p>

Thanks,=

 <= /p>

Muly

 <= /p>

From: Venkates= an Mahalingam [mailto:venkat.mahalingams@gmail.com]
Sent: Tuesday, April 03, 2012 8:42 AM
To: Muly Ilan
Cc: Kannan.Sampath@aricent.com; thomas.nadeau@ca.com; aldrin.ietf@gm= ail.com; mpls@ietf.org
Subject: Re: Comments to draft-ietf-mpls-tp-te-mib-02

 

Muly Ilan, Hi

Sorry for the delayed response.

 

Thanks for the comments. Please find below the reply= tagged [VM].

 

Regards,

Venkat.

On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan <muly_i@rad.com> wrote:

Hi,

 

I have 2 comments to draft-ietf-tp-te-mib-02:=

1.       In mplsXCExtTable – suggest to make the mplsXCExtTunnelPointer a read-only object. The NE can automatically fi= ll in this backward pointer value when the manager sets the mplsTunnelXCPoi= nter in the mplsTunnelTable. This will be simi= lar to the existing backward pointers mplsInSegmentXC= Index & mplsOutSegmentXCIndex.<= /o:p>

[VM] Yes, we will consider this change in our next = version.

2.       In mplsTunnelExtTable – suggest to add a columnar object mplsTunnelExt= RemoteTunnelIndex. This will hold the index of the bidirectional tunnel at = the egress LSR. To support LSP connectivity verification per RFC6428, detec= tion of mis-connectivity defect, the (global-id, node-id, tunnel-num and lsp= -num) should be known at both ends. The global-id and node-id of the remote= LSR are available from mplsNodeConfigTable. Assuming co-routed LSPs, the lsp-num is given by mplsXCLspId. Th= e only missing identifier is the remote tunnel-num since per RFC6370 each e= nd can have its own tunnel number.

[VM] Yes, your suggestion is exactly mat= ching with our next version update. Please find below the expected addition= al MIB objects for mplsTunnelExtTable,

1. mplsTunnelExtDestTnlIndex

2. mplsTunnelExtDestTnlInstance

    3. mplsTunnelExtDestTnlValid - TR= UE/FALSE

       TRUE will be se= t if MIB objects mplsTunnelExtDestTnlIndex and mplsTunnelExtDestTnlInstance= are used for destionation tunnel indentification, FALSE will be set otherw= ise.

    4. mplsTunnelExtOppositeDirTnlVal= id - TRUE/FALSE

     TRUE will be set if MIB obj= ect mplsTunnelOppositeDirPtr is used for destination tunnel identifiction, = FALSE will be set otherwise.

 

 

Regards,

 

Muly Ilan

Senior System Architect, R&D

T: +972-3-765-7035 | M: +972-54-= 470-1004 | F: = +972-3-644-= 0930  | muly_i@rad.com

RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, Israel&nbs= p; | www.rad.com<= /o:p>

 

 

 

--_000_32CB7A1F0806AB4688CE3F22C29DAC87041799FFEXRAD5adradcoil_-- From ice@cisco.com Tue Apr 3 01:25:41 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED66D21F850D for ; Tue, 3 Apr 2012 01:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFaKrI5VecNl for ; Tue, 3 Apr 2012 01:25:41 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9E21F8499 for ; Tue, 3 Apr 2012 01:25:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q338PdaN027424 for ; Tue, 3 Apr 2012 10:25:39 +0200 (CEST) Received: from dhcp-10-55-80-87.cisco.com (dhcp-10-55-80-87.cisco.com [10.55.80.87]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q338Pc7K008509; Tue, 3 Apr 2012 10:25:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: Date: Tue, 3 Apr 2012 10:25:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> To: Chenying (Emily) X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 08:25:42 -0000 Hi Emily, > Thanks for your comments. IMO, the mldp-via-p2p-tunnel and = mldp-node-protection mechanisms are under different situations. The = following is my 2 cents, please see whether this make sense to you. = Thanks. >=20 > The scalability issue would exist only when N node has a large number = of downstream routers. In mLDP deployment scenario, if users want to = upgrade the network into a mLDP capable one, such 'heavy-duty' N node = should be the first priority for upgrade, because it really need packet = duplication functionality. Once the N node is upgraded, then t-ldp is = not needed, and there is no scalability If a router can be upgraded to full mLDP functionality, that always has = the preference. I don't see when you would upgrade it with this = lite-mLDP if the router can support full mLDP. Unless you are talking = about a hardware upgrade/replace of the router. > issue at all. But in mldp-node-protection scenario, such 'heavy-duty' = N node should be the first priority for node protection, because it is = really important for the multicast tree. Then the t-ldp In these cases I would also not apply P2P based node protection to such = heavy-duty router. I would rather rely on HA capability of it. As = discussed during the meeting, there are scalability limitations with P2P = replication.=20 > sessions are always needed, and the scalability issue will always = exist. This is why I think the mldp-via-p2p-tunnel and = mldp-node-protection mechanisms are under different situations. This is the part we disagree on, the scalability limitation of the = solution is not tLDP, its the excessive replication over P2P LSPs and = the increase of bandwidth. Suppose the node N has 100 tLDP sessions = (which is really low), the upstream router potentially has to pump out = 100 times the multicast traffic compared to 1x if node N support mLDP. So in my opinion both solutions have the same considerations, you can = only apply them if the P2P replication is not excissive. Thanks, Ice. >=20 >=20 > Best regards, > Emily Chen=20 >=20 > -----Original Message----- > From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 > Sent: Monday, April 02, 2012 12:34 AM > To: Chenying (Emily); Quintin zhao > Cc: mpls@ietf.org > Subject: Scalability with regards to = draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 >=20 > Dear Emily & Quintin, >=20 > The solution in this draft requires a mLDP router upstream of the = non-mLDP router to do the packet forwarding and replication. The = receiver interest is signaled to the upstream router via tLDP sessions. = The upstream router will end up with the number of tLDP session to all = the of the receivers downstream of the non-mLDP router, and will have to = replicate the multicast packets over P2P LSPs to them.je >=20 > This has exactly the same tLDP scale considerations as discussed in = the context of draft-wijnands-mpls-mldp-node-protection-00, yet for mLDP = node protection it seems to be a concern for you? >=20 > Thx, >=20 > Ice. >=20 > BTW, we already have had a fair bit of discussion on the list Oct 2011 = regarding the other concerns for this draft. >=20 From eosborne@cisco.com Tue Apr 3 04:58:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE54821F8575 for ; Tue, 3 Apr 2012 04:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.293 X-Spam-Level: X-Spam-Status: No, score=-9.293 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9jaUPVsVp1q for ; Tue, 3 Apr 2012 04:58:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id A11F721F8570 for ; Tue, 3 Apr 2012 04:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=20423; q=dns/txt; s=iport; t=1333454286; x=1334663886; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=d1cx0g3uVeKZyXHuYifcOVjOFHGiGi09/E2XRjV/++M=; b=hFFor40PL33c8qCp6Z4qiGAULGm8jdKdRvuG9VdpSMukgPHx5vxDEhd/ fPCD9tP7pwrhGV8cWTGWBxVI4+6XEpFK7inF1ONzsYQpAwfXD8g+m1WIu EP5NyRGs21hFnIWdKbI6fa42ndAegthUWotbqc4UKY5gmEXTUoxuFDEHk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADPlek+tJXG8/2dsb2JhbABFt26BB4IJAQEBAwEBAQEPAR0KNBcEAgEIEQQBAQsGFwEGASYfCQgCBAESCBMHh2IFC5winxWLEoRxYwSIWJtSgWmDBYE2AhU X-IronPort-AV: E=Sophos;i="4.75,362,1330905600"; d="scan'208";a="71645414" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 03 Apr 2012 11:58:05 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.5/8.14.3) with ESMTP id q33Bw550006339; Tue, 3 Apr 2012 11:58:05 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 06:58:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 06:58:03 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0NfcSFnbUIYJaATHaCY55VY+hXbAAC7cHAAADjleAABLiWQAAALkUgAACu52AAAHsFoAAATzmAAACa/MAAAOcgUACgMOpAACJ8hEAAAcTRoAACTMqQABJbWpAAH89j0A== References: From: "Eric Osborne (eosborne)" To: "Gregory Mirsky" , "Maarten vissers" , , "Yaacov Weingarten" , X-OriginalArrivalTime: 03 Apr 2012 11:58:05.0174 (UTC) FILETIME=[072A1160:01CD1191] Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 11:58:08 -0000 Hi Greg- I'm not sure I like 'entity number'. This requires us to define the working LSPs as 'entities' and we hadn't done so either in this draft or in PSC (nor, for that matter, anywhere in TP as far as I can see). What's wrong with just calling it 'priority'? As far as your second point, I still don't think I quite get it. If we use FPath as the priority for a given W-LSP, how will we ever get two W-LSPs of the same priority in the same protection domain? You cannot have two LSPs with FPath=3D6, as there is no way to tell them apart. In other words, FPath is both the identifier *and* the priority, and since the identifier must be unique in a given protection domain the priority is thus unique. We could introduce the idea that operators may configure priorities and that these need to be know a priori, but that's what we started with in the 1ton draft. The concern was raised that this can lead to interop issues. I see two ways out of this: 1) we specify in 1ton that an implementation MUST allow the operator to configure a priority in the range 1..X (perhaps 1..65535?) and that this priority MUST be the same on both ends or else it is a misconfig. The P-LSP for a given domain is, by definition, either priority 0 or above the fray when it comes to priority. 2) we specify that an LSP's FPath is its priority, as I've described above. You seem to be suggesting we require both, and I'm not clear how that would work. eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, April 02, 2012 4:58 PM > To: Maarten vissers; Eric Osborne (eosborne); zhang.fei3@zte.com.cn; > Yaacov Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Dear Maarten, Eric, et al., > I think that "entity number" is good term to use from now in the > discussion. Would you agree? > I think that the first bullet of the Maarten's quote is already present in > the discussed document. Now, IMHO, we need to select what represents > entity number and add appropriate description to case of simultaneous > failure detection of two paths of equal priority. I think that Eric > suggested to use Fpath's index as entity number. I think it is good > solution to my question. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, April 02, 2012 5:15 AM > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > Hi Eric, >=20 > I see where I misunderstood you. "request" in protection switching context > is a reserved term for me. >=20 > What you are looking for is the assignment of what is called "entity > number"s: W1, W2, W3, .. >=20 > These entity numbers are assigned by connection management (NMS or control > plane) when it sets up the protected connections. Both sides have to be > configured with the same entity numbers, otherwise the APS protocol will > fail. >=20 > Because these entity numbers are present, one can re-use those numbers to > express a priority order between Wi and Wj as specified in e.g. G.873.1. > See below: >=20 > ----------------- > [G.873.1] 8.10 Equal priority requests specifies the following: >=20 > - In general, once a switch has been completed due to a request, > it will not be overridden by another request of the same priority > (first come, first served behaviour). >=20 > - When equal priority requests occur simultaneously, the conflict > is resolved in favour of the request with the lowest entity > number. > # In bidirectional switching, a request received over the APS > channel > with a lower entity number will always override an identical > priority > local request with a higher entity number. > # Equal priority requests for the same entity number from both > sides of a bidirectional protection group are both considered > valid, and equivalent to a received "RR" from a near-end > processing > standpoint. > ----------------- >=20 > Regards, > Maarten >=20 > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 12:57 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 >=20 > I'm not sure that answers my question, although it may be that it does and > I don't understand it. >=20 > I think what you're talking about is the alarm hierarchy; that is, if I > get both LOP and FS on the same LSP, FS 'wins'. We have this behavior in > 1:1 PSC already. What we're trying to sort out with 1:n is what happens > when two LSPs encounter the same failure condition. >=20 > If Wx and Wy both get SF, only one of them can be protected in 1:n. In > order to decide which one we need something deterministic. Talking about > 'priority' and 'tie-breakers' as if they were different makes no sense in > this context. If two LSPs are of the same priority due to a priority > config on a network device, the tie-breaker will be something else. As > you and others have suggested, we can require the nodes to rely on the > signaled FPath value, standardizing the fact that the lower value is alway > of better priority. >=20 > The question Greg originally raised was essentially "how do we know what > that priority scheme is?" Our answer heretofore in the 1:n drafts has > been "depends on the device, and both devices have to agree" but the more > I look at it the more that doesn't make sense. >=20 > I think what we need is something akin to what you pointed out earlier is > already done in MSP; lower numeric value for FPath always wins. >=20 >=20 >=20 >=20 >=20 > eric >=20 > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Monday, April 02, 2012 6:06 AM > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > > > The standard specifies the priority order of requests. E.g. in G.873.1 > > (OTN linear protection, > > http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107= - > > I!!PDF-E&type=3Ditems > > REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following specification > is > > included: > > > > 8.3 Request type > > The request types that may be reflected in the APS bytes are the > > "standard" types traditionally supported by protection switching for > SONET > > and SDH. These requests reflect the highest priority condition, > command, > > or state (see Tables 2 and 3). In the case of unidirectional > switching, > > this is the highest priority value determined from the near end only. > In > > bidirectional switching, the local request will be indicated only in > the > > case where it is as high or higher than any request received from the > far > > end over the APS channel. In bidirectional switching, when the far end > > request has the highest priority, the near end will signal Reverse > > Request. > > Table 2/G.873.1 - Request/state priorities with APS protocol > > Request/state Priority > > Lockout for Protection (LoP) 1 (highest) > > Signal Fail (SF) - protection 2 (see 8.9) > > Forced Switch (FS) 3 > > Signal Fail (SF) - working 4 > > Signal Degrade (SD) 5 > > Manual Switch (MS) 6 > > Wait-to-Restore (WTR) 7 > > Exercise (EXER) 8 > > Reverse Request (RR) 9 > > Do Not Revert (DNR) 10 > > No Request (NR) 11 (lowest) > > Table 3/G.873.1 - Request/state priorities without APS protocol > > Request/state Priority > > Lockout for Protection (LoP) 1 (highest) > > Forced Switch (FS) 2 > > Signal Fail (SF) 3 > > Signal Degrade (SD) 4 > > Manual Switch (MS) 5 > > Wait-to-Restore (WTR) 6 > > Do Not Revert (DNR) 7 > > No Request (NR) 8 (lowest) > > > > > > > > Regards, > > Maarten > > > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: maandag 2 april 2012 11:56 > > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Maarten- > > > > How does a node know that two requests are of equal priority? Is this > > somehow configured a priori on the MSP endpoints? > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > > Sent: Thursday, March 29, 2012 3:06 PM > > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > > protection): > > > > > > 8.10 Equal priority requests > > > In general, once a switch has been completed due to a request, it > will > > not > > > be overridden by another request of the same priority (first come, > > first > > > served behaviour). When equal priority requests occur > simultaneously, > > the > > > conflict is resolved in favour of the request with the lowest entity > > > number. In bidirectional switching, a request received over the APS > > > channel with a lower entity number will always override an identical > > > priority local request with a higher entity number. Equal priority > > > requests for the same entity number from both sides of a > bidirectional > > > protection group are both considered valid, and equivalent to a > > received > > > "RR" from a near-end processing standpoint. > > > > > > Regards, > > > Maarten > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Maarten vissers > > > Sent: donderdag 29 maart 2012 14:54 > > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > > Yaacov > > > Weingarten; mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > 1:n protection in a transport network at the path layer is not a > very > > > common protection switching application. This is due to the fact > that > > 1:n > > > protection requires n+1 diverse routed paths. How many of those > > diverse > > > routed paths will be available in typical transport networks? Not > > many... > > > very often two diverse routed paths is all you can get... and this > is > > only > > > truly guaranteed over time if the network domain is organized as > > separate > > > A and a B networks. Otherwise maintenance on the network may result > in > > > temporary rerouting of virtual links, resulting in routing W and P > > > connections over the same fiber, node or duct. > > > > > > With n>2, separate networks can not be used and one has to find n+1 > > > diverse routed paths through the network and guarantee that neither > > > maintenance activities, nor network upgrades result in rerouting of > > the > > > virtual links so that W and P connections pass through the same > fiber, > > > node or duct. > > > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line > card > > > protection (end of 90's). > > > > > > Regards, > > > Maarten > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of > > > Eric Osborne (eosborne) > > > Sent: donderdag 29 maart 2012 14:31 > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > I still go back to my point that since only one W can ever use P, > > there > > > really is no such thing as 'equal priority'. We must have a > priority > > > scheme, whether it is the channel number in Fpath or whether it's > some > > > other mechanism, so that we know that Wi always beats Wj no matter > > what > > > order the events occur in. > > > > > > We had initially discussed leaving the exact priority scheme to the > > > protection endpoints, but I see now that that may not work well > across > > > vendors. > > > > > > I think we have a few choices: > > > > > > 1) some sort of explicit priority field > > > 2) define priority as the FPath value, lower is better (as Maarten > > > points out, this is the current practice in SDH). > > > > > > Either one of these have costs to them. > > > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and > in > > > locking mode means nobody is protected until both ends converge. > This > > > also makes things (potentially) very dynamic which is, I think, not > > what > > > we want in a protocol that has to converge in real time. > > > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > > to > > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > > How > > > often does this sort of thing happen in transport networks? Is it a > > > real problem? > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 2:21 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > Hi Eric, > > > > I agree with your logic and that current document handles scenario > > you > > > > present (prioties of simulteneously failed paths are different) > > well. > > > But > > > > I still am concerned with case when priorities of Wi and Wj are > > equal. > > > If > > > > you think that it might present a problem, then I see two possible > > > ways to > > > > address: > > > > - disallow multiple LSPs being assigned equal priority (not the > best > > > way); > > > > - define tiebreaking rule(s). > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 5:11 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Let me rewrite the messages a little bit in your example. Rather > > than > > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > > LSPs > > > in > > > > question. And let's also say that the priority of Wi > Wj, just > as > > > you > > > > have done. > > > > > > > > I also note that setting Path=3D=3D0 means you're using locking mode. > > > This is > > > > certainly a valid case, I just want to confirm that it's your > > > intention? > > > > > > > > at t0, no failure. > > > > > > > > at t1, > > > > LER-A sends SF(Wi,0) to LER-Z > > > > AND > > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has > already > > > > decided that Wi needs the protect channel. > > > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > > t3, > > > > shortly after t2. > > > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > > unidirectional locking preemption case, as in section 3.3.3.2 of > the > > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is > what > > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. > Since > > it > > > is > > > > locking, no transmission of packets takes place since neither side > > had > > > > ACKd the other side's SF. > > > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > -----Original Message----- > > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > > Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > Hi Eric, > > > > > Below is scenario that in my view would benefit from a > tiebreaking > > > > rule. > > > > > Would appreciate your consideration and feedback whether this is > > > > realistic > > > > > and not breaking PSC: > > > > > - Assume that LSP P is not being used or used by working path of > > > > priority > > > > > N; > > > > > - LER-A detects failure of working path Wi of priority M, where > M > > > > > > N, > > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > > - almost simulteneously, at least before it receives SF from > > LER-A, > > > > LER-Z > > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > > listing > > > > Wj > > > > > as Fpath; > > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) = =3D=3D > > > > Priority(Wj) > > > > > would not change to protecting Wi path; > > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason > would > > > keep > > > > Wi > > > > > as path to protect. > > > > > Is that sequence, scenario correct? Would LER-A and LER-Z > converge > > > on > > > > > selecting one path they'd protect? > > > > > > > > > > Regards, > > > > > Greg > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > > priority". > > > > > > There must be a tiebreaker that can handle all possible > > conflicts, > > > > no > > > > > > matter what order or how many failures. Once there is a > > > > deterministic > > > > > > mechanism for all cases, it means that all LSPs are of > different > > > > > priority. > > > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > > failure > > > > > of > > > > > > two working paths of equal priority. Otherwise, equal priority > > > would > > > > > not > > > > > > preempt one that is already is using the protection path, i.e. > > > FIFO > > > > > will > > > > > > fully work in this case. > > > > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. > In > > > 1:n > > > > we'd > > > > > always made the assumption that, in a given protection domain, > > only > > > a > > > > > single W can be protected at a time. To do otherwise (say, W1 > and > > > W2 > > > > > using P) is not possible using PSC signaling since we can only > > > > indicate a > > > > > single LSP in the FPath field. > > > > > > > > > > Nothing precludes multiple protection domains from using the > same > > > > > underlying link and/or same endpoints, but that's a network > design > > > > > consideration. > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > From emily.chenying@huawei.com Tue Apr 3 10:40:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040AC11E809F for ; Tue, 3 Apr 2012 10:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgD2OB8EI25v for ; Tue, 3 Apr 2012 10:40:58 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 45E0511E8095 for ; Tue, 3 Apr 2012 10:40:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX75591; Tue, 03 Apr 2012 13:40:57 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 10:40:16 -0700 Received: from SZXEML428-HUB.china.huawei.com (10.72.61.36) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 10:40:19 -0700 Received: from SZXEML537-MBX.china.huawei.com ([169.254.1.146]) by szxeml428-hub.china.huawei.com ([10.72.61.36]) with mapi id 14.01.0323.003; Wed, 4 Apr 2012 01:40:12 +0800 From: "Chenying (Emily)" To: IJsbrand Wijnands Thread-Topic: Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AQHNEKMHzQzVy2RitkKshuY+flYZW5aIAKKAgAA+rgCAARbeQA== Date: Tue, 3 Apr 2012 17:40:11 +0000 Message-ID: References: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 17:40:59 -0000 Please see [Emily] inline, thanks. Best regards, Emily Chen=20 -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 Sent: Tuesday, April 03, 2012 1:26 AM To: Chenying (Emily) Cc: mpls@ietf.org Subject: Re: Scalability with regards to draft-chen-mpls-mldp-deployment-vi= a-p2p-tunnels-00 Hi Emily, > Thanks for your comments. IMO, the mldp-via-p2p-tunnel and mldp-node-prot= ection mechanisms are under different situations. The following is my 2 cen= ts, please see whether this make sense to you. Thanks. >=20 > The scalability issue would exist only when N node has a large number of = downstream routers. In mLDP deployment scenario, if users want to upgrade t= he network into a mLDP capable one, such 'heavy-duty' N node should be the = first priority for upgrade, because it really need packet duplication funct= ionality. Once the N node is upgraded, then t-ldp is not needed, and there = is no scalability If a router can be upgraded to full mLDP functionality, that always has the= preference. I don't see when you would upgrade it with this lite-mLDP if t= he router can support full mLDP. Unless you are talking about a hardware up= grade/replace of the router. [Emily] Yes, I was talking about a hardware upgrade or replacement. If user= has an upgrade list in hand, it is reasonable to put such 'heavy-duty' nod= e at the first priority for fully upgrade. Then there is no t-ldp issue ove= r it. In other words, the mldp-via-p2p mechanism is likely to be used on th= ose less-important nodes, which might temporally not get the chance of upgr= ading hardware.=20 > issue at all. But in mldp-node-protection scenario, such 'heavy-duty' N n= ode should be the first priority for node protection, because it is really = important for the multicast tree. Then the t-ldp In these cases I would also not apply P2P based node protection to such hea= vy-duty router. I would rather rely on HA capability of it. As discussed du= ring the meeting, there are scalability limitations with P2P replication.=20 [Emily] Not sure what kind of 'HA capability' you are talking about? Anyway= , I totally agree with you that p2p-based node protection is not a good ide= a for such 'heavy-duty' node. > sessions are always needed, and the scalability issue will always exist. = This is why I think the mldp-via-p2p-tunnel and mldp-node-protection mechan= isms are under different situations. This is the part we disagree on, the scalability limitation of the solution= is not tLDP, its the excessive replication over P2P LSPs and the increase = of bandwidth. Suppose the node N has 100 tLDP sessions (which is really low= ), the upstream router potentially has to pump out 100 times the multicast = traffic compared to 1x if node N support mLDP. [Emily] I think we are on the same page. Indeed, p2p duplication is a bigge= r issue than maintaining the t-ldp sessions. But it might be not a good ide= a to ignore the risk/burden of maintaining the huge number of t-ldp session= s when there is other issue. So in my opinion both solutions have the same considerations, you can only = apply them if the P2P replication is not excissive. [Emily] If both solutions are deployed on the same 'heavy-duty' node, they = indeed have the same scalability issues on both t-ldp sessions and p2p repl= ications. But what I am trying to say is that, in real deployment, such 'he= avy-duty' node has less chance to deploy mldp-via-p2p-tunnel because it sho= uld be fully upgrade, but it has more possibility to deploy mldp-node-prote= ction because it is really important for the multicast tree. Thanks, Ice. >=20 >=20 > Best regards, > Emily Chen=20 >=20 > -----Original Message----- > From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 > Sent: Monday, April 02, 2012 12:34 AM > To: Chenying (Emily); Quintin zhao > Cc: mpls@ietf.org > Subject: Scalability with regards to draft-chen-mpls-mldp-deployment-via-= p2p-tunnels-00 >=20 > Dear Emily & Quintin, >=20 > The solution in this draft requires a mLDP router upstream of the non-mLD= P router to do the packet forwarding and replication. The receiver interest= is signaled to the upstream router via tLDP sessions. The upstream router = will end up with the number of tLDP session to all the of the receivers dow= nstream of the non-mLDP router, and will have to replicate the multicast pa= ckets over P2P LSPs to them.je >=20 > This has exactly the same tLDP scale considerations as discussed in the c= ontext of draft-wijnands-mpls-mldp-node-protection-00, yet for mLDP node pr= otection it seems to be a concern for you? >=20 > Thx, >=20 > Ice. >=20 > BTW, we already have had a fair bit of discussion on the list Oct 2011 re= garding the other concerns for this draft. >=20 From ice@cisco.com Tue Apr 3 11:05:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E2311E80B6 for ; Tue, 3 Apr 2012 11:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzjHYYPqBogQ for ; Tue, 3 Apr 2012 11:05:46 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7AB11E80CA for ; Tue, 3 Apr 2012 11:05:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q33I5AO0002425 for ; Tue, 3 Apr 2012 20:05:10 +0200 (CEST) Received: from dhcp-10-61-96-94.cisco.com (dhcp-10-61-96-94.cisco.com [10.61.96.94]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q33I54DC016702; Tue, 3 Apr 2012 20:05:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: IJsbrand Wijnands In-Reply-To: Date: Tue, 3 Apr 2012 20:05:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B19B2AB-F024-45C2-929A-DFE82D10B1F3@cisco.com> References: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> To: Chenying (Emily) X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 18:05:46 -0000 Emily, > [Emily] Not sure what kind of 'HA capability' you are talking about? = Anyway, I totally agree with you that p2p-based node protection is not a = good idea for such 'heavy-duty' node. HA means High Availability, it protects the router from a control plane = failure by having dual RP's in hot standby mode. It allows the router to = do Non Stop Forwarding (NSF) and recover from control plane failure = while continuing to forward. This improves the reliability and uptime of = the router making it less necessary to apply node protection. This is = typically a feature that high end routers have. Thx, Ice. From emily.chenying@huawei.com Tue Apr 3 11:32:34 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBB11E8083 for ; Tue, 3 Apr 2012 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IV+P53ZadpS for ; Tue, 3 Apr 2012 11:32:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id F073011E8075 for ; Tue, 3 Apr 2012 11:32:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX78700; Tue, 03 Apr 2012 14:32:33 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 11:31:30 -0700 Received: from SZXEML439-HUB.china.huawei.com (10.72.61.74) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 3 Apr 2012 11:31:26 -0700 Received: from SZXEML537-MBX.china.huawei.com ([169.254.1.146]) by szxeml439-hub.china.huawei.com ([10.72.61.74]) with mapi id 14.01.0323.003; Wed, 4 Apr 2012 02:31:23 +0800 From: "Chenying (Emily)" To: IJsbrand Wijnands Thread-Topic: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 Thread-Index: AQHNEKMHzQzVy2RitkKshuY+flYZW5aIAKKAgAA+rgCAARbeQP//iwQAgACL6pA= Date: Tue, 3 Apr 2012 18:31:22 +0000 Message-ID: References: <8939D5E6-DD63-4D73-A1B5-286AB2449244@cisco.com> <3B19B2AB-F024-45C2-929A-DFE82D10B1F3@cisco.com> In-Reply-To: <3B19B2AB-F024-45C2-929A-DFE82D10B1F3@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 18:32:34 -0000 Oh, I thought you were saying other protection mechanisms such as p2mp base= d protection. :-) I totally agree that GR or NSR can help a lot when control plane fails. But= what if there is a power-off accident, or the protected node just crashes?= That's the situations for which we are working hard to develop an ideal pr= otection mechanism. Best regards, Emily Chen=20 -----Original Message----- From: IJsbrand Wijnands [mailto:ice@cisco.com]=20 Sent: Tuesday, April 03, 2012 11:05 AM To: Chenying (Emily) Cc: mpls@ietf.org Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deploy= ment-via-p2p-tunnels-00 Emily, > [Emily] Not sure what kind of 'HA capability' you are talking about? Anyw= ay, I totally agree with you that p2p-based node protection is not a good i= dea for such 'heavy-duty' node. HA means High Availability, it protects the router from a control plane fai= lure by having dual RP's in hot standby mode. It allows the router to do N= on Stop Forwarding (NSF) and recover from control plane failure while conti= nuing to forward. This improves the reliability and uptime of the router ma= king it less necessary to apply node protection. This is typically a featur= e that high end routers have. Thx, Ice. From wyaacov@gmail.com Tue Apr 3 12:40:25 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E08811E81BB for ; Tue, 3 Apr 2012 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu+Vvk78AQVK for ; Tue, 3 Apr 2012 12:40:22 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4109C11E81BC for ; Tue, 3 Apr 2012 12:40:20 -0700 (PDT) Received: by qaea16 with SMTP id a16so186726qae.10 for ; Tue, 03 Apr 2012 12:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9XzrwDkKGIkC+b4aNh11j3MNa7gEAixUG65q9bgkMRE=; b=K+o0t0fLru6eqIswb7tsXl3f4Gs06EOb4UzxZz9Owi67imE9PVmoFlGyhDxOFTNoEC 31E94MS00kcMKLhIGtN507/mTtie8tcfuFmR7r/Nz6vGUJ0yrJkgv7JqiaBWt6u/SROk zA6fLyXNnP4sGrhw7AYikwbCXqN6H6UFcsPy/UmZcH6orDcrZLB7TM1af3ZVWZTfs7K3 TGzISESf+/9LKvFNtxwoLZyvb17wonDfIMirgWsHVw39TS5MaUqjXPBMDwz/tS2rIabb j5PUWbMPF+/5IXBLxYyAcYbpBjdjE34EURabuloFYLvuplSFsCkB0ZWoZTixkAToE02x Hesw== MIME-Version: 1.0 Received: by 10.224.214.66 with SMTP id gz2mr17588476qab.22.1333482018653; Tue, 03 Apr 2012 12:40:18 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Tue, 3 Apr 2012 12:40:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Apr 2012 22:40:18 +0300 Message-ID: From: Yaacov Weingarten To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=20cf3005dcf60945bc04bccb7acf Cc: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 19:40:25 -0000 --20cf3005dcf60945bc04bccb7acf Content-Type: text/plain; charset=ISO-8859-1 Eric, et.al., hi I am not sure what the confusion is - I think your first option is the proper way for us to go, i.e. the operator can configure a "priority" for an LSP that must be coordinated with both endpoints, and possibly causing a misconfiguration error - this process [i.e. of assigning the priorities and checking for misconfiguration] should be out-of-scope of the 1:n draft. The Path identifier (1..127) is only used as a "tiebreaker" in case two working paths are simultaneously reporting an error condition that needs to be protected. This "tiebreaker" definition could be documented in the I-D to address Greg's original comments. Just my opinion, yaacov On Tue, Apr 3, 2012 at 2:58 PM, Eric Osborne (eosborne) wrote: > Hi Greg- > > I'm not sure I like 'entity number'. This requires us to define the > working LSPs as 'entities' and we hadn't done so either in this draft or > in PSC (nor, for that matter, anywhere in TP as far as I can see). > What's wrong with just calling it 'priority'? > > As far as your second point, I still don't think I quite get it. If > we use FPath as the priority for a given W-LSP, how will we ever get two > W-LSPs of the same priority in the same protection domain? You cannot > have two LSPs with FPath=6, as there is no way to tell them apart. In > other words, FPath is both the identifier *and* the priority, and since > the identifier must be unique in a given protection domain the priority > is thus unique. > > We could introduce the idea that operators may configure priorities > and that these need to be know a priori, but that's what we started with > in the 1ton draft. The concern was raised that this can lead to interop > issues. I see two ways out of this: > > > 1) we specify in 1ton that an implementation MUST allow the operator to > configure a priority in the range 1..X (perhaps 1..65535?) and that > this priority MUST be the same on both ends or else it is a misconfig. > The P-LSP for a given domain is, by definition, either priority 0 or > above the fray when it comes to priority. > > 2) we specify that an LSP's FPath is its priority, as I've described > above. > > > You seem to be suggesting we require both, and I'm not clear how that > would work. > > > > > > eric > > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Monday, April 02, 2012 4:58 PM > > To: Maarten vissers; Eric Osborne (eosborne); zhang.fei3@zte.com.cn; > > Yaacov Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Dear Maarten, Eric, et al., > > I think that "entity number" is good term to use from now in the > > discussion. Would you agree? > > I think that the first bullet of the Maarten's quote is already > present in > > the discussed document. Now, IMHO, we need to select what represents > > entity number and add appropriate description to case of simultaneous > > failure detection of two paths of equal priority. I think that Eric > > suggested to use Fpath's index as entity number. I think it is good > > solution to my question. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Monday, April 02, 2012 5:15 AM > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > > > I see where I misunderstood you. "request" in protection switching > context > > is a reserved term for me. > > > > What you are looking for is the assignment of what is called "entity > > number"s: W1, W2, W3, .. > > > > These entity numbers are assigned by connection management (NMS or > control > > plane) when it sets up the protected connections. Both sides have to > be > > configured with the same entity numbers, otherwise the APS protocol > will > > fail. > > > > Because these entity numbers are present, one can re-use those numbers > to > > express a priority order between Wi and Wj as specified in e.g. > G.873.1. > > See below: > > > > ----------------- > > [G.873.1] 8.10 Equal priority requests specifies the following: > > > > - In general, once a switch has been completed due to a request, > > it will not be overridden by another request of the same > priority > > (first come, first served behaviour). > > > > - When equal priority requests occur simultaneously, the > conflict > > is resolved in favour of the request with the lowest entity > > number. > > # In bidirectional switching, a request received over the APS > > channel > > with a lower entity number will always override an identical > > priority > > local request with a higher entity number. > > # Equal priority requests for the same entity number from both > > sides of a bidirectional protection group are both > considered > > valid, and equivalent to a received "RR" from a near-end > > processing > > standpoint. > > ----------------- > > > > Regards, > > Maarten > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: maandag 2 april 2012 12:57 > > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > I'm not sure that answers my question, although it may be that it does > and > > I don't understand it. > > > > I think what you're talking about is the alarm hierarchy; that is, if > I > > get both LOP and FS on the same LSP, FS 'wins'. We have this behavior > in > > 1:1 PSC already. What we're trying to sort out with 1:n is what > happens > > when two LSPs encounter the same failure condition. > > > > If Wx and Wy both get SF, only one of them can be protected in 1:n. > In > > order to decide which one we need something deterministic. Talking > about > > 'priority' and 'tie-breakers' as if they were different makes no sense > in > > this context. If two LSPs are of the same priority due to a priority > > config on a network device, the tie-breaker will be something else. > As > > you and others have suggested, we can require the nodes to rely on the > > signaled FPath value, standardizing the fact that the lower value is > alway > > of better priority. > > > > The question Greg originally raised was essentially "how do we know > what > > that priority scheme is?" Our answer heretofore in the 1:n drafts has > > been "depends on the device, and both devices have to agree" but the > more > > I look at it the more that doesn't make sense. > > > > I think what we need is something akin to what you pointed out earlier > is > > already done in MSP; lower numeric value for FPath always wins. > > > > > > > > > > > > eric > > > > > -----Original Message----- > > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > > Sent: Monday, April 02, 2012 6:06 AM > > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > > Yaacov > > > Weingarten; mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Eric, > > > > > > The standard specifies the priority order of requests. E.g. in > G.873.1 > > > (OTN linear protection, > > > > http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.873.1-201107- > > > I!!PDF-E&type=items > > > > REC-G.873.1-201107-I!!PDF-E&type=items> ) the following > specification > > is > > > included: > > > > > > 8.3 Request type > > > The request types that may be reflected in the APS bytes are the > > > "standard" types traditionally supported by protection switching for > > SONET > > > and SDH. These requests reflect the highest priority condition, > > command, > > > or state (see Tables 2 and 3). In the case of unidirectional > > switching, > > > this is the highest priority value determined from the near end > only. > > In > > > bidirectional switching, the local request will be indicated only in > > the > > > case where it is as high or higher than any request received from > the > > far > > > end over the APS channel. In bidirectional switching, when the far > end > > > request has the highest priority, the near end will signal Reverse > > > Request. > > > Table 2/G.873.1 - Request/state priorities with APS protocol > > > Request/state Priority > > > Lockout for Protection (LoP) 1 (highest) > > > Signal Fail (SF) - protection 2 (see 8.9) > > > Forced Switch (FS) 3 > > > Signal Fail (SF) - working 4 > > > Signal Degrade (SD) 5 > > > Manual Switch (MS) 6 > > > Wait-to-Restore (WTR) 7 > > > Exercise (EXER) 8 > > > Reverse Request (RR) 9 > > > Do Not Revert (DNR) 10 > > > No Request (NR) 11 (lowest) > > > Table 3/G.873.1 - Request/state priorities without APS protocol > > > Request/state Priority > > > Lockout for Protection (LoP) 1 (highest) > > > Forced Switch (FS) 2 > > > Signal Fail (SF) 3 > > > Signal Degrade (SD) 4 > > > Manual Switch (MS) 5 > > > Wait-to-Restore (WTR) 6 > > > Do Not Revert (DNR) 7 > > > No Request (NR) 8 (lowest) > > > > > > > > > > > > Regards, > > > Maarten > > > > > > > > > -----Original Message----- > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > Sent: maandag 2 april 2012 11:56 > > > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > > > Weingarten; mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Hi Maarten- > > > > > > How does a node know that two requests are of equal priority? Is > this > > > somehow configured a priori on the MSP endpoints? > > > > > > > > > > > > > > > eric > > > > > > > > > > -----Original Message----- > > > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > > > Sent: Thursday, March 29, 2012 3:06 PM > > > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > > > zhang.fei3@zte.com.cn; Yaacov Weingarten; mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > > > protection): > > > > > > > > 8.10 Equal priority requests > > > > In general, once a switch has been completed due to a request, it > > will > > > not > > > > be overridden by another request of the same priority (first come, > > > first > > > > served behaviour). When equal priority requests occur > > simultaneously, > > > the > > > > conflict is resolved in favour of the request with the lowest > entity > > > > number. In bidirectional switching, a request received over the > APS > > > > channel with a lower entity number will always override an > identical > > > > priority local request with a higher entity number. Equal priority > > > > requests for the same entity number from both sides of a > > bidirectional > > > > protection group are both considered valid, and equivalent to a > > > received > > > > "RR" from a near-end processing standpoint. > > > > > > > > Regards, > > > > Maarten > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Maarten vissers > > > > Sent: donderdag 29 maart 2012 14:54 > > > > To: Eric Osborne (eosborne); Gregory Mirsky; > zhang.fei3@zte.com.cn; > > > Yaacov > > > > Weingarten; mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > 1:n protection in a transport network at the path layer is not a > > very > > > > common protection switching application. This is due to the fact > > that > > > 1:n > > > > protection requires n+1 diverse routed paths. How many of those > > > diverse > > > > routed paths will be available in typical transport networks? Not > > > many... > > > > very often two diverse routed paths is all you can get... and this > > is > > > only > > > > truly guaranteed over time if the network domain is organized as > > > separate > > > > A and a B networks. Otherwise maintenance on the network may > result > > in > > > > temporary rerouting of virtual links, resulting in routing W and P > > > > connections over the same fiber, node or duct. > > > > > > > > With n>2, separate networks can not be used and one has to find > n+1 > > > > diverse routed paths through the network and guarantee that > neither > > > > maintenance activities, nor network upgrades result in rerouting > of > > > the > > > > virtual links so that W and P connections pass through the same > > fiber, > > > > node or duct. > > > > > > > > 1:n protection has been used in SDH/SONET for SDH/SONET > regenerator > > > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line > > card > > > > protection (end of 90's). > > > > > > > > Regards, > > > > Maarten > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Eric Osborne (eosborne) > > > > Sent: donderdag 29 maart 2012 14:31 > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > I still go back to my point that since only one W can ever use P, > > > there > > > > really is no such thing as 'equal priority'. We must have a > > priority > > > > scheme, whether it is the channel number in Fpath or whether it's > > some > > > > other mechanism, so that we know that Wi always beats Wj no matter > > > what > > > > order the events occur in. > > > > > > > > We had initially discussed leaving the exact priority scheme to > the > > > > protection endpoints, but I see now that that may not work well > > across > > > > vendors. > > > > > > > > I think we have a few choices: > > > > > > > > 1) some sort of explicit priority field > > > > 2) define priority as the FPath value, lower is better (as Maarten > > > > points out, this is the current practice in SDH). > > > > > > > > Either one of these have costs to them. > > > > > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 > has > > > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, > and > > in > > > > locking mode means nobody is protected until both ends converge. > > This > > > > also makes things (potentially) very dynamic which is, I think, > not > > > what > > > > we want in a protocol that has to converge in real time. > > > > > > > > Doing #2 means that if I have W1...W5 already provisioned and I > want > > > to > > > > add W3.1, I need to reprovision W4 and W5, which may be > disruptive. > > > How > > > > often does this sort of thing happen in transport networks? Is it > a > > > > real problem? > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > -----Original Message----- > > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > > Sent: Thursday, March 29, 2012 2:21 PM > > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > > Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > > > Hi Eric, > > > > > I agree with your logic and that current document handles > scenario > > > you > > > > > present (prioties of simulteneously failed paths are different) > > > well. > > > > But > > > > > I still am concerned with case when priorities of Wi and Wj are > > > equal. > > > > If > > > > > you think that it might present a problem, then I see two > possible > > > > ways to > > > > > address: > > > > > - disallow multiple LSPs being assigned equal priority (not the > > best > > > > way); > > > > > - define tiebreaking rule(s). > > > > > > > > > > Regards, > > > > > Greg > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > > Sent: Thursday, March 29, 2012 5:11 AM > > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > Let me rewrite the messages a little bit in your example. > Rather > > > than > > > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > > > LSPs > > > > in > > > > > question. And let's also say that the priority of Wi > Wj, just > > as > > > > you > > > > > have done. > > > > > > > > > > I also note that setting Path==0 means you're using locking > mode. > > > > This is > > > > > certainly a valid case, I just want to confirm that it's your > > > > intention? > > > > > > > > > > at t0, no failure. > > > > > > > > > > at t1, > > > > > LER-A sends SF(Wi,0) to LER-Z > > > > > AND > > > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has > > already > > > > > decided that Wi needs the protect channel. > > > > > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or > at > > > t3, > > > > > shortly after t2. > > > > > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > > > unidirectional locking preemption case, as in section 3.3.3.2 of > > the > > > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is > > what > > > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. > > Since > > > it > > > > is > > > > > locking, no transmission of packets takes place since neither > side > > > had > > > > > ACKd the other side's SF. > > > > > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > > > -----Original Message----- > > > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > > > Weingarten; > > > > > > mpls@ietf.org > > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > Hi Eric, > > > > > > Below is scenario that in my view would benefit from a > > tiebreaking > > > > > rule. > > > > > > Would appreciate your consideration and feedback whether this > is > > > > > realistic > > > > > > and not breaking PSC: > > > > > > - Assume that LSP P is not being used or used by working path > of > > > > > priority > > > > > > N; > > > > > > - LER-A detects failure of working path Wi of priority M, > where > > M > > > > > > > > N, > > > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > > > - almost simulteneously, at least before it receives SF from > > > LER-A, > > > > > LER-Z > > > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > > > listing > > > > > Wj > > > > > > as Fpath; > > > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) == > > > > > Priority(Wj) > > > > > > would not change to protecting Wi path; > > > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason > > would > > > > keep > > > > > Wi > > > > > > as path to protect. > > > > > > Is that sequence, scenario correct? Would LER-A and LER-Z > > converge > > > > on > > > > > > selecting one path they'd protect? > > > > > > > > > > > > Regards, > > > > > > Greg > > > > > > > > > > > > -----Original Message----- > > > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > > > mpls@ietf.org > > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the > "same > > > > > > priority". > > > > > > > There must be a tiebreaker that can handle all possible > > > conflicts, > > > > > no > > > > > > > matter what order or how many failures. Once there is a > > > > > deterministic > > > > > > > mechanism for all cases, it means that all LSPs are of > > different > > > > > > priority. > > > > > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > > > failure > > > > > > of > > > > > > > two working paths of equal priority. Otherwise, equal > priority > > > > would > > > > > > not > > > > > > > preempt one that is already is using the protection path, > i.e. > > > > FIFO > > > > > > will > > > > > > > fully work in this case. > > > > > > > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. > > In > > > > 1:n > > > > > we'd > > > > > > always made the assumption that, in a given protection domain, > > > only > > > > a > > > > > > single W can be protected at a time. To do otherwise (say, W1 > > and > > > > W2 > > > > > > using P) is not possible using PSC signaling since we can only > > > > > indicate a > > > > > > single LSP in the FPath field. > > > > > > > > > > > > Nothing precludes multiple protection domains from using the > > same > > > > > > underlying link and/or same endpoints, but that's a network > > design > > > > > > consideration. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > --20cf3005dcf60945bc04bccb7acf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric, et.al., hi

I am not s= ure what the confusion is - I think your first option is the proper way for= us to go, i.e. the operator can configure a "priority" for an LS= P that must be coordinated with both endpoints, and possibly causing a misc= onfiguration error - this process [i.e. of assigning the priorities and che= cking for misconfiguration] should be out-of-scope of the 1:n draft. =A0The= Path identifier (1..127) is only used as a "tiebreaker" in case = two working paths are simultaneously reporting an error condition that need= s to be protected. =A0This "tiebreaker" definition could be docum= ented in the I-D to address Greg's original comments.

Just my opinion,

yaacov
On Tue, Apr 3, 2012 at 2:58 PM, Eric Osborne (e= osborne) <eosbor= ne@cisco.com> wrote:
Hi Greg-

=A0I'm not sure I like 'entity number'. =A0This requires us to= define the
working LSPs as 'entities' and we hadn't done so either in this= draft or
in PSC (nor, for that matter, anywhere in TP as far as I can see).
What's wrong with just calling it 'priority'?

=A0As far as your second point, I still don't think I quite get it. = =A0If
we use FPath as the priority for a given W-LSP, how will we ever get two W-LSPs of the same priority in the same protection domain? =A0You cannot have two LSPs with FPath=3D6, as there is no way to tell them apart. =A0In<= br> other words, FPath is both the identifier *and* the priority, and since
the identifier must be unique in a given protection domain the priority
is thus unique.

=A0We could introduce the idea that operators may configure priorities
and that these need to be know a priori, but that's what we started wit= h
in the 1ton draft. =A0The concern was raised that this can lead to interop<= br> issues. =A0I see two ways out of this:


1) we specify in 1ton that an implementation MUST allow the operator to
configure a priority in the range 1..X =A0(perhaps 1..65535?) and that
this priority MUST be the same on both ends or else it is a misconfig.
The P-LSP for a given domain is, by definition, either priority 0 or
above the fray when it comes to priority.

2) we specify that an LSP's FPath is its priority, as I've describe= d
above.


You seem to be suggesting we require both, and I'm not clear how that would work.





eric

> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Monday, April 02, = 2012 4:58 PM
> To: Maarten vissers; Eric Osborne (eosborne); zhang.fei3@zte.com.cn;
> Yaacov Weingarten; mpls@ietf.org<= br> > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> Dear Maarten, Eric, et al.,
> I think that "entity number" is good term to use from now in= the
> discussion. Would you agree?
> I think that the first bullet of the Maarten's quote is already present in
> the discussed document. Now, IMHO, we need to select what represents > entity number and add appropriate description to case of simultaneous<= br> > failure detection of two paths of equal priority. I think that Eric > suggested to use Fpath's index as entity number. I think it is goo= d
> solution to my question.
>
> =A0 =A0 =A0 =A0 Regards,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Greg
>
> -----Original Message-----
> From: Maarten vissers [mailto:maarten.vissers@huawei.com]
> Sent: Monday, April 02, 2012 5:15 AM
> To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn;
Yaacov
> Weingarten; mpls@ietf.org
> Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> Hi Eric,
>
> I see where I misunderstood you. "request" in protection swi= tching
context
> is a reserved term for me.
>
> What you are looking for is the assignment of what is called "ent= ity
> number"s: W1, W2, W3, ..
>
> These entity numbers are assigned by connection management (NMS or
control
> plane) when it sets up the protected connections. Both sides have to be
> configured with the same entity numbers, otherwise the APS protocol will
> fail.
>
> Because these entity numbers are present, one can re-use those numbers=
to
> express a priority order between Wi and Wj as specified in e.g.
G.873.1.
> See below:
>
> -----------------
> [G.873.1] 8.10 =A0Equal priority requests specifies the following:
>
> - =A0 =A0 =A0 In general, once a switch has been completed due to a re= quest,
> =A0 =A0 =A0 =A0 it will not be overridden by another request of the sa= me
priority
> =A0 =A0 =A0 =A0 (first come, first served behaviour).
>
> - =A0 =A0 =A0 When equal priority requests occur simultaneously, the conflict
> =A0 =A0 =A0 =A0 is resolved in favour of the request with the lowest e= ntity
> number.
> =A0 =A0 =A0 =A0 # In bidirectional switching, a request received over = the APS
> channel
> =A0 =A0 =A0 =A0 =A0 with a lower entity number will always override an= identical
> priority
> =A0 =A0 =A0 =A0 =A0 local request with a higher entity number.
> =A0 =A0 =A0 =A0 # Equal priority requests for the same entity number f= rom both
> =A0 =A0 =A0 =A0 =A0 sides of a bidirectional protection group are both=
considered
> =A0 =A0 =A0 =A0 =A0 valid, and equivalent to a received "RR"= from a near-end
> processing
> =A0 =A0 =A0 =A0 =A0 standpoint.
> -----------------
>
> Regards,
> Maarten
>
> -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> Sent: maandag 2 april 2012 12:57
> To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov
> Weingarten; mpls@ietf.org
> Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> I'm not sure that answers my question, although it may be that it = does
and
> I don't understand it.
>
> I think what you're talking about is the alarm hierarchy; that is,= if
I
> get both LOP and FS on the same LSP, FS 'wins'. =A0We have thi= s behavior
in
> 1:1 PSC already. =A0What we're trying to sort out with 1:n is what=
happens
> when two LSPs encounter the same failure condition.
>
> If Wx and Wy both get SF, only one of them can be protected in 1:n. In
> order to decide which one we need something deterministic. =A0Talking<= br> about
> 'priority' and 'tie-breakers' as if they were differen= t makes no sense
in
> this context. =A0If two LSPs are of the same priority due to a priorit= y
> config on a network device, the tie-breaker will be something else. As
> you and others have suggested, we can require the nodes to rely on the=
> signaled FPath value, standardizing the fact that the lower value is alway
> of better priority.
>
> The question Greg originally raised was essentially "how do we kn= ow
what
> that priority scheme is?" =A0Our answer heretofore in the 1:n dra= fts has
> been "depends on the device, and both devices have to agree"= but the
more
> I look at it the more that doesn't make sense.
>
> I think what we need is something akin to what you pointed out earlier=
is
> already done in MSP; lower numeric value for FPath always wins.
>
>
>
>
>
> eric
>
> > -----Original Message-----
> > From: Maarten vissers [mailto:maarten.vissers@huawei.com]
> > Sent: Monday, April 02, 2012 6:06 AM
> > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn;
> Yaacov
> > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> > Hi Eric,
> >
> > The standard specifies the priority order of requests. E.g. in G.873.1
> > (OTN linear protection,
> >
http://www.itu.int/rec/dologin_pub.asp?la= ng=3De&id=3DT-REC-G.873.1-201107-
> > I!!PDF-E&type=3Ditems
> <http://www.itu.int/rec/dologin_pub.asp?lang=3De&am= p;id=3DT-
> > REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following<= br> specification
> is
> > included:
> >
> > 8.3 =A0 =A0 Request type
> > The request types that may be reflected in the APS bytes are the<= br> > > "standard" types traditionally supported by protection = switching for
> SONET
> > and SDH. These requests reflect the highest priority condition, > command,
> > or state (see Tables 2 and 3). In the case of unidirectional
> switching,
> > this is the highest priority value determined from the near end only.
> In
> > bidirectional switching, the local request will be indicated only= in
> the
> > case where it is as high or higher than any request received from=
the
> far
> > end over the APS channel. In bidirectional switching, when the fa= r
end
> > request has the highest priority, the near end will signal Revers= e
> > Request.
> > Table 2/G.873.1 - Request/state priorities with APS protocol
> > Request/state =A0Priority
> > Lockout for Protection (LoP) =A0 1 (highest)
> > Signal Fail (SF) - protection =A02 (see 8.9)
> > Forced Switch (FS) =A0 =A0 3
> > Signal Fail (SF) - working =A0 =A0 4
> > Signal Degrade (SD) =A0 =A05
> > Manual Switch (MS) =A0 =A0 6
> > Wait-to-Restore (WTR) =A07
> > Exercise (EXER) =A0 =A0 =A0 =A08
> > Reverse Request (RR) =A0 9
> > Do Not Revert (DNR) =A0 =A010
> > No Request (NR) =A0 =A0 =A0 =A011 (lowest)
> > Table 3/G.873.1 - Request/state priorities without APS protocol > > Request/state =A0Priority
> > Lockout for Protection (LoP) =A0 1 (highest)
> > Forced Switch (FS) =A0 =A0 2
> > Signal Fail (SF) =A0 =A0 =A0 3
> > Signal Degrade (SD) =A0 =A04
> > Manual Switch (MS) =A0 =A0 5
> > Wait-to-Restore (WTR) =A06
> > Do Not Revert (DNR) =A0 =A07
> > No Request (NR) =A0 =A0 =A0 =A08 (lowest)
> >
> >
> >
> > Regards,
> > Maarten
> >
> >
> > -----Original Message-----
> > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > Sent: maandag 2 april 2012 11:56
> > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov
> > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >
> > Hi Maarten-
> >
> > How does a node know that two requests are of equal priority? =A0= Is
this
> > somehow configured a priori on the MSP endpoints?
> >
> >
> >
> >
> > eric
> >
> >
> > > -----Original Message-----
> > > From: Maarten vissers [mailto:maarten.vissers@huawei.com]
> > > Sent: Thursday, March 29, 2012 3:06 PM
> > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky= ;
> > > zhang.fei3@zte.com.= cn; Yaacov Weingarten; mpls@ietf.org
> > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > >
> > > Below is a copy of the equal priority text in G.873.1 (OTN l= inear
> > > protection):
> > >
> > > 8.10 =A0Equal priority requests
> > > In general, once a switch has been completed due to a reques= t, it
> will
> > not
> > > be overridden by another request of the same priority (first= come,
> > first
> > > served behaviour). When equal priority requests occur
> simultaneously,
> > the
> > > conflict is resolved in favour of the request with the lowes= t
entity
> > > number. In bidirectional switching, a request received over = the
APS
> > > channel with a lower entity number will always override an identical
> > > priority local request with a higher entity number. Equal pr= iority
> > > requests for the same entity number from both sides of a
> bidirectional
> > > protection group are both considered valid, and equivalent t= o a
> > received
> > > "RR" from a near-end processing standpoint.
> > >
> > > Regards,
> > > Maarten
> > >
> > > -----Original Message-----
> > > From: mpls-bounces@= ietf.org [mailto:mpls-bounces@= ietf.org] On
Behalf
> > Of
> > > Maarten vissers
> > > Sent: donderdag 29 maart 2012 14:54
> > > To: Eric Osborne (eosborne); Gregory Mirsky;
zhang.fei3@zte.com.cn;
> > Yaacov
> > > Weingarten; mpls@ietf.org
> > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protecti= on-01
> > >
> > > 1:n protection in a transport network at the path layer is n= ot a
> very
> > > common protection switching application. This is due to the = fact
> that
> > 1:n
> > > protection requires n+1 diverse routed paths. How many of th= ose
> > diverse
> > > routed paths will be available in typical transport networks= ? Not
> > many...
> > > very often two diverse routed paths is all you can get... an= d this
> is
> > only
> > > truly guaranteed over time if the network domain is organize= d as
> > separate
> > > A and a B networks. Otherwise maintenance on the network may=
result
> in
> > > temporary rerouting of virtual links, resulting in routing W= and P
> > > connections over the same fiber, node or duct.
> > >
> > > With n>2, separate networks can not be used and one has t= o find
n+1
> > > diverse routed paths through the network and guarantee that<= br> neither
> > > maintenance activities, nor network upgrades result in rerou= ting
of
> > the
> > > virtual links so that W and P connections pass through the s= ame
> fiber,
> > > node or duct.
> > >
> > > 1:n protection has been used in SDH/SONET for SDH/SONET
regenerator
> > > protection (1:7 and 1:11 systems, in early 90's) and for= SDH line
> card
> > > protection (end of 90's).
> > >
> > > Regards,
> > > Maarten
> > >
> > > -----Original Message-----
> > > From: mpls-bounces@= ietf.org [mailto:mpls-bounces@= ietf.org] On
Behalf
> > Of
> > > Eric Osborne (eosborne)
> > > Sent: donderdag 29 maart 2012 14:31
> > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;
> > > mpls@ietf.org
> > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protecti= on-01
> > >
> > > I still go back to my point that since only one W can ever u= se P,
> > there
> > > really is no such thing as 'equal priority'. =A0We m= ust have a
> priority
> > > scheme, whether it is the channel number in Fpath or whether= it's
> some
> > > other mechanism, so that we know that Wi always beats Wj no = matter
> > what
> > > order the events occur in.
> > >
> > > We had initially discussed leaving the exact priority scheme= to
the
> > > protection endpoints, but I see now that that may not work w= ell
> across
> > > vendors.
> > >
> > > I think we have a few choices:
> > >
> > > 1) some sort of explicit priority field
> > > 2) define priority as the FPath value, lower is better (as M= aarten
> > > points out, this is the current practice in SDH).
> > >
> > > Either one of these have costs to them.
> > >
> > > Doing #1 leaves us with a potential mismatch; if LER-A think= s W2
has
> > > prio1 and LER-Z thinks W3 has prio1, sorting this out is mes= sy,
and
> in
> > > locking mode means nobody is protected until both ends conve= rge.
> This
> > > also makes things (potentially) very dynamic which is, I thi= nk,
not
> > what
> > > we want in a protocol that has to converge in real time.
> > >
> > > Doing #2 means that if I have W1...W5 already provisioned an= d I
want
> > to
> > > add W3.1, I need to reprovision W4 and W5, which may be
disruptive.
> > How
> > > often does this sort of thing happen in transport networks? = =A0Is it
a
> > > real problem?
> > >
> > >
> > >
> > >
> > > eric
> > >
> > > > -----Original Message-----
> > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> > > > Sent: Thursday, March 29, 2012 2:21 PM
> > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov
> > Weingarten;
> > > > mpls@ietf.org
> > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection= -01
> > > >
> > > >
> > > > Hi Eric,
> > > > I agree with your logic and that current document handl= es
scenario
> > you
> > > > present (prioties of simulteneously failed paths are di= fferent)
> > well.
> > > But
> > > > I still am concerned with case when priorities of Wi an= d Wj are
> > equal.
> > > If
> > > > you think that it might present a problem, then I see t= wo
possible
> > > ways to
> > > > address:
> > > > - disallow multiple LSPs being assigned equal priority = (not the
> best
> > > way);
> > > > - define tiebreaking rule(s).
> > > >
> > > > =A0 =A0 =A0Regards,
> > > > =A0 =A0 =A0 =A0 =A0 =A0 =A0Greg
> > > >
> > > > -----Original Message-----
> > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > > > Sent: Thursday, March 29, 2012 5:11 AM
> > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;
> > > > mpls@ietf.org
> > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection= -01
> > > >
> > > > Let me rewrite the messages a little bit in your exampl= e.
Rather
> > than
> > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi a= nd Wj are the
> > LSPs
> > > in
> > > > question. =A0And let's also say that the priority o= f Wi > Wj, just
> as
> > > you
> > > > have done.
> > > >
> > > > I also note that setting Path=3D=3D0 means you're u= sing locking
mode.
> > > This is
> > > > certainly a valid case, I just want to confirm that it&= #39;s your
> > > intention?
> > > >
> > > > at t0, no failure.
> > > >
> > > > at t1,
> > > > =A0 LER-A sends SF(Wi,0) to LER-Z
> > > > =A0 =A0 AND
> > > > =A0 LER-Z sends SF(Wj,0) to LER-Z
> > > >
> > > > at t2, LER-A receives SF(Wj,0). =A0It ignores it, since= it has
> already
> > > > decided that Wi needs the protect channel.
> > > >
> > > > LER-Z also receives SF(Wi,0). =A0This is either exactly= at t2, or
at
> > t3,
> > > > shortly after t2.
> > > >
> > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats t= his as a
> > > > unidirectional locking preemption case, as in section 3= .3.3.2 of
> the
> > > > draft. =A0LER-Z responds to the SF(Wi,0) with NR(Wi,0).= =A0This is
> what
> > > > 3.3.3.2 describes as LER-A's behavior at t1.
> > > >
> > > > In this way, both LER-A and LER-Z converge on protectin= g Wi.
> Since
> > it
> > > is
> > > > locking, no transmission of packets takes place since n= either
side
> > had
> > > > ACKd the other side's SF.
> > > >
> > > > Does that reflect your question, and does it answer it?=
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > eric
> > > >
> > > > > -----Original Message-----
> > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> > > > > Sent: Thursday, March 29, 2012 1:51 PM
> > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov
> > > Weingarten;
> > > > > mpls@ietf.org=
> > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-prote= ction-01
> > > > >
> > > > > Hi Eric,
> > > > > Below is scenario that in my view would benefit fr= om a
> tiebreaking
> > > > rule.
> > > > > Would appreciate your consideration and feedback w= hether this
is
> > > > realistic
> > > > > and not breaking PSC:
> > > > > - Assume that LSP P is not being used or used by w= orking path
of
> > > > priority
> > > > > N;
> > > > > - LER-A detects failure of working path Wi of prio= rity M,
where
> M
> > >
> > > N,
> > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath;<= br> > > > > > - almost simulteneously, at least before it receiv= es SF from
> > LER-A,
> > > > LER-Z
> > > > > detects failure of Wj that has priority M. LER-Z s= ends SF(1,0)
> > > listing
> > > > Wj
> > > > > as Fpath;
> > > > > - LER-Z receives SF(1,0) from LER-A and since Prio= rity(Wi) =3D=3D
> > > > Priority(Wj)
> > > > > would not change to protecting Wi path;
> > > > > - LER-A receives SF(1,0) from LER-Z and for the sa= me reason
> would
> > > keep
> > > > Wi
> > > > > as path to protect.
> > > > > Is that sequence, scenario correct? Would LER-A an= d LER-Z
> converge
> > > on
> > > > > selecting one path they'd protect?
> > > > >
> > > > > =A0 =A0Regards,
> > > > > =A0 =A0 =A0 =A0 =A0 =A0Greg
> > > > >
> > > > > -----Original Message-----
> > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > > > > Sent: Thursday, March 29, 2012 4:38 AM
> > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten;
> > > > > mpls@ietf.org=
> > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-prote= ction-01
> > > > >
> > > > >
> > > > > > EO# =A0I would argue that one should not have= LSPs of the
"same
> > > > > priority".
> > > > > > There must be a tiebreaker that can handle al= l possible
> > conflicts,
> > > > no
> > > > > > matter what order or how many failures. =A0On= ce there is a
> > > > deterministic
> > > > > > mechanism for all cases, it means that all LS= Ps are of
> different
> > > > > priority.
> > > > > >
> > > > > > GIM>> Tiebreaking would be used only in= case of simulteneous
> > > failure
> > > > > of
> > > > > > two working paths of equal priority. Otherwis= e, equal
priority
> > > would
> > > > > not
> > > > > > preempt one that is already is using the prot= ection path,
i.e.
> > > FIFO
> > > > > will
> > > > > > fully work in this case.
> > > > >
> > > > >
> > > > > I think the behavior you describe is more about SM= P than 1:n.
> In
> > > 1:n
> > > > we'd
> > > > > always made the assumption that, in a given protec= tion domain,
> > only
> > > a
> > > > > single W can be protected at a time. =A0To do othe= rwise (say, W1
> and
> > > W2
> > > > > using P) is not possible using PSC signaling since= we can only
> > > > indicate a
> > > > > single LSP in the FPath field.
> > > > >
> > > > > Nothing precludes multiple protection domains from= using the
> same
> > > > > underlying link and/or same endpoints, but that= 9;s a network
> design
> > > > > consideration.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > eric
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> >

--20cf3005dcf60945bc04bccb7acf-- From gregory.mirsky@ericsson.com Tue Apr 3 13:13:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC82811E81C6 for ; Tue, 3 Apr 2012 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CF-XeAFPYQU for ; Tue, 3 Apr 2012 13:13:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C91A111E81C9 for ; Tue, 3 Apr 2012 13:13:23 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q33KDHxc014341; Tue, 3 Apr 2012 15:13:18 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 3 Apr 2012 16:13:13 -0400 From: Gregory Mirsky To: Yaacov Weingarten , "Eric Osborne (eosborne)" Date: Tue, 3 Apr 2012 16:13:11 -0400 Thread-Topic: Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0R0aj56ukcAaQqTjqzbtbdDNf7ZgAAcClQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135510FF47FEUSAACMS0715e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 20:13:27 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135510FF47FEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Yaacov, et al., Path Identifier is a reference to one of N LSPs that share the protection L= SP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear Pr= otection PSC message from PSC message in 1:n?) need to find failed LSP prio= rity. I think it might be reasonable to signal priority of failed path alon= g with the Failed Path Index in a TLV, hence making it mandatory in PSCv.2. Regards, Greg ________________________________ From: Yaacov Weingarten [mailto:wyaacov@gmail.com] Sent: Tuesday, April 03, 2012 12:40 PM To: Eric Osborne (eosborne) Cc: Gregory Mirsky; Maarten vissers; zhang.fei3@zte.com.cn; mpls@ietf.org Subject: Re: Comments on draft-ezy-mpls-1ton-protection-01 Eric, et.al., hi I am not sure what the confusion is - I think your first option is the prop= er way for us to go, i.e. the operator can configure a "priority" for an LS= P that must be coordinated with both endpoints, and possibly causing a misc= onfiguration error - this process [i.e. of assigning the priorities and che= cking for misconfiguration] should be out-of-scope of the 1:n draft. The P= ath identifier (1..127) is only used as a "tiebreaker" in case two working = paths are simultaneously reporting an error condition that needs to be prot= ected. This "tiebreaker" definition could be documented in the I-D to addr= ess Greg's original comments. Just my opinion, yaacov On Tue, Apr 3, 2012 at 2:58 PM, Eric Osborne (eosborne) > wrote: Hi Greg- I'm not sure I like 'entity number'. This requires us to define the working LSPs as 'entities' and we hadn't done so either in this draft or in PSC (nor, for that matter, anywhere in TP as far as I can see). What's wrong with just calling it 'priority'? As far as your second point, I still don't think I quite get it. If we use FPath as the priority for a given W-LSP, how will we ever get two W-LSPs of the same priority in the same protection domain? You cannot have two LSPs with FPath=3D6, as there is no way to tell them apart. In other words, FPath is both the identifier *and* the priority, and since the identifier must be unique in a given protection domain the priority is thus unique. We could introduce the idea that operators may configure priorities and that these need to be know a priori, but that's what we started with in the 1ton draft. The concern was raised that this can lead to interop issues. I see two ways out of this: 1) we specify in 1ton that an implementation MUST allow the operator to configure a priority in the range 1..X (perhaps 1..65535?) and that this priority MUST be the same on both ends or else it is a misconfig. The P-LSP for a given domain is, by definition, either priority 0 or above the fray when it comes to priority. 2) we specify that an LSP's FPath is its priority, as I've described above. You seem to be suggesting we require both, and I'm not clear how that would work. eric > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Monday, April 02, 2012 4:58 PM > To: Maarten vissers; Eric Osborne (eosborne); zhang.fei3@zte.com.cn; > Yaacov Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > Dear Maarten, Eric, et al., > I think that "entity number" is good term to use from now in the > discussion. Would you agree? > I think that the first bullet of the Maarten's quote is already present in > the discussed document. Now, IMHO, we need to select what represents > entity number and add appropriate description to case of simultaneous > failure detection of two paths of equal priority. I think that Eric > suggested to use Fpath's index as entity number. I think it is good > solution to my question. > > Regards, > Greg > > -----Original Message----- > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > Sent: Monday, April 02, 2012 5:15 AM > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > Hi Eric, > > I see where I misunderstood you. "request" in protection switching context > is a reserved term for me. > > What you are looking for is the assignment of what is called "entity > number"s: W1, W2, W3, .. > > These entity numbers are assigned by connection management (NMS or control > plane) when it sets up the protected connections. Both sides have to be > configured with the same entity numbers, otherwise the APS protocol will > fail. > > Because these entity numbers are present, one can re-use those numbers to > express a priority order between Wi and Wj as specified in e.g. G.873.1. > See below: > > ----------------- > [G.873.1] 8.10 Equal priority requests specifies the following: > > - In general, once a switch has been completed due to a request, > it will not be overridden by another request of the same priority > (first come, first served behaviour). > > - When equal priority requests occur simultaneously, the conflict > is resolved in favour of the request with the lowest entity > number. > # In bidirectional switching, a request received over the APS > channel > with a lower entity number will always override an identical > priority > local request with a higher entity number. > # Equal priority requests for the same entity number from both > sides of a bidirectional protection group are both considered > valid, and equivalent to a received "RR" from a near-end > processing > standpoint. > ----------------- > > Regards, > Maarten > > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: maandag 2 april 2012 12:57 > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > Weingarten; mpls@ietf.org > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > I'm not sure that answers my question, although it may be that it does and > I don't understand it. > > I think what you're talking about is the alarm hierarchy; that is, if I > get both LOP and FS on the same LSP, FS 'wins'. We have this behavior in > 1:1 PSC already. What we're trying to sort out with 1:n is what happens > when two LSPs encounter the same failure condition. > > If Wx and Wy both get SF, only one of them can be protected in 1:n. In > order to decide which one we need something deterministic. Talking about > 'priority' and 'tie-breakers' as if they were different makes no sense in > this context. If two LSPs are of the same priority due to a priority > config on a network device, the tie-breaker will be something else. As > you and others have suggested, we can require the nodes to rely on the > signaled FPath value, standardizing the fact that the lower value is alway > of better priority. > > The question Greg originally raised was essentially "how do we know what > that priority scheme is?" Our answer heretofore in the 1:n drafts has > been "depends on the device, and both devices have to agree" but the more > I look at it the more that doesn't make sense. > > I think what we need is something akin to what you pointed out earlier is > already done in MSP; lower numeric value for FPath always wins. > > > > > > eric > > > -----Original Message----- > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > Sent: Monday, April 02, 2012 6:06 AM > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Eric, > > > > The standard specifies the priority order of requests. E.g. in G.873.1 > > (OTN linear protection, > > http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3DT-REC-G.873.1-201107- > > I!!PDF-E&type=3Ditems > > REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the following specification > is > > included: > > > > 8.3 Request type > > The request types that may be reflected in the APS bytes are the > > "standard" types traditionally supported by protection switching for > SONET > > and SDH. These requests reflect the highest priority condition, > command, > > or state (see Tables 2 and 3). In the case of unidirectional > switching, > > this is the highest priority value determined from the near end only. > In > > bidirectional switching, the local request will be indicated only in > the > > case where it is as high or higher than any request received from the > far > > end over the APS channel. In bidirectional switching, when the far end > > request has the highest priority, the near end will signal Reverse > > Request. > > Table 2/G.873.1 - Request/state priorities with APS protocol > > Request/state Priority > > Lockout for Protection (LoP) 1 (highest) > > Signal Fail (SF) - protection 2 (see 8.9) > > Forced Switch (FS) 3 > > Signal Fail (SF) - working 4 > > Signal Degrade (SD) 5 > > Manual Switch (MS) 6 > > Wait-to-Restore (WTR) 7 > > Exercise (EXER) 8 > > Reverse Request (RR) 9 > > Do Not Revert (DNR) 10 > > No Request (NR) 11 (lowest) > > Table 3/G.873.1 - Request/state priorities without APS protocol > > Request/state Priority > > Lockout for Protection (LoP) 1 (highest) > > Forced Switch (FS) 2 > > Signal Fail (SF) 3 > > Signal Degrade (SD) 4 > > Manual Switch (MS) 5 > > Wait-to-Restore (WTR) 6 > > Do Not Revert (DNR) 7 > > No Request (NR) 8 (lowest) > > > > > > > > Regards, > > Maarten > > > > > > -----Original Message----- > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > Sent: maandag 2 april 2012 11:56 > > To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov > > Weingarten; mpls@ietf.org > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > Hi Maarten- > > > > How does a node know that two requests are of equal priority? Is this > > somehow configured a priori on the MSP endpoints? > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > From: Maarten vissers [mailto:maarten.vissers@huawei.com] > > > Sent: Thursday, March 29, 2012 3:06 PM > > > To: Maarten vissers; Eric Osborne (eosborne); Gregory Mirsky; > > > zhang.fei3@zte.com.cn; Yaacov Weingarte= n; mpls@ietf.org > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > Below is a copy of the equal priority text in G.873.1 (OTN linear > > > protection): > > > > > > 8.10 Equal priority requests > > > In general, once a switch has been completed due to a request, it > will > > not > > > be overridden by another request of the same priority (first come, > > first > > > served behaviour). When equal priority requests occur > simultaneously, > > the > > > conflict is resolved in favour of the request with the lowest entity > > > number. In bidirectional switching, a request received over the APS > > > channel with a lower entity number will always override an identical > > > priority local request with a higher entity number. Equal priority > > > requests for the same entity number from both sides of a > bidirectional > > > protection group are both considered valid, and equivalent to a > > received > > > "RR" from a near-end processing standpoint. > > > > > > Regards, > > > Maarten > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpl= s-bounces@ietf.org] On Behalf > > Of > > > Maarten vissers > > > Sent: donderdag 29 maart 2012 14:54 > > > To: Eric Osborne (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn; > > Yaacov > > > Weingarten; mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > 1:n protection in a transport network at the path layer is not a > very > > > common protection switching application. This is due to the fact > that > > 1:n > > > protection requires n+1 diverse routed paths. How many of those > > diverse > > > routed paths will be available in typical transport networks? Not > > many... > > > very often two diverse routed paths is all you can get... and this > is > > only > > > truly guaranteed over time if the network domain is organized as > > separate > > > A and a B networks. Otherwise maintenance on the network may result > in > > > temporary rerouting of virtual links, resulting in routing W and P > > > connections over the same fiber, node or duct. > > > > > > With n>2, separate networks can not be used and one has to find n+1 > > > diverse routed paths through the network and guarantee that neither > > > maintenance activities, nor network upgrades result in rerouting of > > the > > > virtual links so that W and P connections pass through the same > fiber, > > > node or duct. > > > > > > 1:n protection has been used in SDH/SONET for SDH/SONET regenerator > > > protection (1:7 and 1:11 systems, in early 90's) and for SDH line > card > > > protection (end of 90's). > > > > > > Regards, > > > Maarten > > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpl= s-bounces@ietf.org] On Behalf > > Of > > > Eric Osborne (eosborne) > > > Sent: donderdag 29 maart 2012 14:31 > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > mpls@ietf.org > > > Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > I still go back to my point that since only one W can ever use P, > > there > > > really is no such thing as 'equal priority'. We must have a > priority > > > scheme, whether it is the channel number in Fpath or whether it's > some > > > other mechanism, so that we know that Wi always beats Wj no matter > > what > > > order the events occur in. > > > > > > We had initially discussed leaving the exact priority scheme to the > > > protection endpoints, but I see now that that may not work well > across > > > vendors. > > > > > > I think we have a few choices: > > > > > > 1) some sort of explicit priority field > > > 2) define priority as the FPath value, lower is better (as Maarten > > > points out, this is the current practice in SDH). > > > > > > Either one of these have costs to them. > > > > > > Doing #1 leaves us with a potential mismatch; if LER-A thinks W2 has > > > prio1 and LER-Z thinks W3 has prio1, sorting this out is messy, and > in > > > locking mode means nobody is protected until both ends converge. > This > > > also makes things (potentially) very dynamic which is, I think, not > > what > > > we want in a protocol that has to converge in real time. > > > > > > Doing #2 means that if I have W1...W5 already provisioned and I want > > to > > > add W3.1, I need to reprovision W4 and W5, which may be disruptive. > > How > > > often does this sort of thing happen in transport networks? Is it a > > > real problem? > > > > > > > > > > > > > > > eric > > > > > > > -----Original Message----- > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > Sent: Thursday, March 29, 2012 2:21 PM > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > Hi Eric, > > > > I agree with your logic and that current document handles scenario > > you > > > > present (prioties of simulteneously failed paths are different) > > well. > > > But > > > > I still am concerned with case when priorities of Wi and Wj are > > equal. > > > If > > > > you think that it might present a problem, then I see two possible > > > ways to > > > > address: > > > > - disallow multiple LSPs being assigned equal priority (not the > best > > > way); > > > > - define tiebreaking rule(s). > > > > > > > > Regards, > > > > Greg > > > > > > > > -----Original Message----- > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > Sent: Thursday, March 29, 2012 5:11 AM > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > mpls@ietf.org > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > Let me rewrite the messages a little bit in your example. Rather > > than > > > > SF(1,0), let's use SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the > > LSPs > > > in > > > > question. And let's also say that the priority of Wi > Wj, just > as > > > you > > > > have done. > > > > > > > > I also note that setting Path=3D=3D0 means you're using locking mode. > > > This is > > > > certainly a valid case, I just want to confirm that it's your > > > intention? > > > > > > > > at t0, no failure. > > > > > > > > at t1, > > > > LER-A sends SF(Wi,0) to LER-Z > > > > AND > > > > LER-Z sends SF(Wj,0) to LER-Z > > > > > > > > at t2, LER-A receives SF(Wj,0). It ignores it, since it has > already > > > > decided that Wi needs the protect channel. > > > > > > > > LER-Z also receives SF(Wi,0). This is either exactly at t2, or at > > t3, > > > > shortly after t2. > > > > > > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this as a > > > > unidirectional locking preemption case, as in section 3.3.3.2 of > the > > > > draft. LER-Z responds to the SF(Wi,0) with NR(Wi,0). This is > what > > > > 3.3.3.2 describes as LER-A's behavior at t1. > > > > > > > > In this way, both LER-A and LER-Z converge on protecting Wi. > Since > > it > > > is > > > > locking, no transmission of packets takes place since neither side > > had > > > > ACKd the other side's SF. > > > > > > > > Does that reflect your question, and does it answer it? > > > > > > > > > > > > > > > > > > > > > > > > eric > > > > > > > > > -----Original Message----- > > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > > > > Sent: Thursday, March 29, 2012 1:51 PM > > > > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov > > > Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > Hi Eric, > > > > > Below is scenario that in my view would benefit from a > tiebreaking > > > > rule. > > > > > Would appreciate your consideration and feedback whether this is > > > > realistic > > > > > and not breaking PSC: > > > > > - Assume that LSP P is not being used or used by working path of > > > > priority > > > > > N; > > > > > - LER-A detects failure of working path Wi of priority M, where > M > > > > > > N, > > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath; > > > > > - almost simulteneously, at least before it receives SF from > > LER-A, > > > > LER-Z > > > > > detects failure of Wj that has priority M. LER-Z sends SF(1,0) > > > listing > > > > Wj > > > > > as Fpath; > > > > > - LER-Z receives SF(1,0) from LER-A and since Priority(Wi) =3D=3D > > > > Priority(Wj) > > > > > would not change to protecting Wi path; > > > > > - LER-A receives SF(1,0) from LER-Z and for the same reason > would > > > keep > > > > Wi > > > > > as path to protect. > > > > > Is that sequence, scenario correct? Would LER-A and LER-Z > converge > > > on > > > > > selecting one path they'd protect? > > > > > > > > > > Regards, > > > > > Greg > > > > > > > > > > -----Original Message----- > > > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > > > > > Sent: Thursday, March 29, 2012 4:38 AM > > > > > To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov Weingarten; > > > > > mpls@ietf.org > > > > > Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01 > > > > > > > > > > > > > > > > EO# I would argue that one should not have LSPs of the "same > > > > > priority". > > > > > > There must be a tiebreaker that can handle all possible > > conflicts, > > > > no > > > > > > matter what order or how many failures. Once there is a > > > > deterministic > > > > > > mechanism for all cases, it means that all LSPs are of > different > > > > > priority. > > > > > > > > > > > > GIM>> Tiebreaking would be used only in case of simulteneous > > > failure > > > > > of > > > > > > two working paths of equal priority. Otherwise, equal priority > > > would > > > > > not > > > > > > preempt one that is already is using the protection path, i.e. > > > FIFO > > > > > will > > > > > > fully work in this case. > > > > > > > > > > > > > > > I think the behavior you describe is more about SMP than 1:n. > In > > > 1:n > > > > we'd > > > > > always made the assumption that, in a given protection domain, > > only > > > a > > > > > single W can be protected at a time. To do otherwise (say, W1 > and > > > W2 > > > > > using P) is not possible using PSC signaling since we can only > > > > indicate a > > > > > single LSP in the FPath field. > > > > > > > > > > Nothing precludes multiple protection domains from using the > same > > > > > underlying link and/or same endpoints, but that's a network > design > > > > > consideration. > > > > > > > > > > > > > > > > > > > > > > > > > eric > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > --_000_FE60A4E52763E84B935532D7D9294FF135510FF47FEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Yaacov, et al.,
Path Identifier is a reference to one of N&nb= sp;LSPs=20 that share the protection LSP. LER that recieves PSCv.2 (do we need ac= ronym=20 to differentiate Linear Protection PSC message from PSC message in 1:n?) ne= ed to=20 find failed LSP priority. I think it might be reasonable to signal priority= of=20 failed path along with the Failed Path Index in a TLV, hence making it mand= atory=20 in PSCv.2.
 
  &n= bsp; Regards,
        Greg

From: Yaacov Weingarten=20 [mailto:wyaacov@gmail.com]
Sent: Tuesday, April 03, 2012 12:40=20 PM
To: Eric Osborne (eosborne)
Cc: Gregory Mirsky; Maar= ten=20 vissers; zhang.fei3@zte.com.cn; mpls@ietf.org
Subject: Re: Commen= ts on=20 draft-ezy-mpls-1ton-protection-01

Eric, et.al., hi

I am not sure what the confusion is - I think your first option is the= =20 proper way for us to go, i.e. the operator can configure a "priority" for a= n LSP=20 that must be coordinated with both endpoints, and possibly causing a=20 misconfiguration error - this process [i.e. of assigning the priorities and= =20 checking for misconfiguration] should be out-of-scope of the 1:n draft.=20  The Path identifier (1..127) is only used as a "tiebreaker" in case t= wo=20 working paths are simultaneously reporting an error condition that needs to= be=20 protected.  This "tiebreaker" definition could be documented in the I-= D to=20 address Greg's original comments.

Just my opinion,

yaacov

On Tue, Apr 3, 2012 at 2:58 PM, Eric Osborne (eosb= orne)=20 <eosborne@cisco.com> wrote:=
Hi=20 Greg-

 I'm not sure I like 'entity number'.  This requir= es us=20 to define the
working LSPs as 'entities' and we hadn't done so either = in=20 this draft or
in PSC (nor, for that matter, anywhere in TP as far as I= can=20 see).
What's wrong with just calling it 'priority'?

 As fa= r as=20 your second point, I still don't think I quite get it.  If
we use= =20 FPath as the priority for a given W-LSP, how will we ever get two
W-LS= Ps of=20 the same priority in the same protection domain?  You cannot
have= two=20 LSPs with FPath=3D6, as there is no way to tell them apart.  In
o= ther=20 words, FPath is both the identifier *and* the priority, and since
the= =20 identifier must be unique in a given protection domain the priority
is= thus=20 unique.

 We could introduce the idea that operators may confi= gure=20 priorities
and that these need to be know a priori, but that's what we= =20 started with
in the 1ton draft.  The concern was raised that this= can=20 lead to interop
issues.  I see two ways out of this:


1= ) we=20 specify in 1ton that an implementation MUST allow the operator to
conf= igure=20 a priority in the range 1..X  (perhaps 1..65535?) and that
this=20 priority MUST be the same on both ends or else it is a misconfig.
The = P-LSP=20 for a given domain is, by definition, either priority 0 or
above the f= ray=20 when it comes to priority.

2) we specify that an LSP's FPath is it= s=20 priority, as I've described
above.


You seem to be suggestin= g we=20 require both, and I'm not clear how that
would work.





eric

> -----Origin= al=20 Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Monday, April 02, 2012 4:58 PM
> To: Maa= rten=20 vissers; Eric Osborne (eosborne); zhang.fei3@zte.com.cn;
> = Yaacov=20 Weingarten; mpls@ietf.org
> Su= bject:=20 RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> Dear=20 Maarten, Eric, et al.,
> I think that "entity number" is good term = to=20 use from now in the
> discussion. Would you agree?
> I think = that=20 the first bullet of the Maarten's quote is already
present in
> = the=20 discussed document. Now, IMHO, we need to select what represents
>= =20 entity number and add appropriate description to case of simultaneous
= >=20 failure detection of two paths of equal priority. I think that Eric
&g= t;=20 suggested to use Fpath's index as entity number. I think it is good
&g= t;=20 solution to my question.
>
>        =20 Regards,
>                = =20 Greg
>
> -----Original Message-----
> From: Maarten vis= sers=20 [mailto:maarten.vissers@huawei.com= ]
>=20 Sent: Monday, April 02, 2012 5:15 AM
> To: Eric Osborne (eosborne);= =20 Gregory Mirsky; zhang.fei3@zte.com.cn;
Yaaco= v
>=20 Weingarten; mpls@ietf.org
> Su= bject:=20 RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> Hi=20 Eric,
>
> I see where I misunderstood you. "request" in prote= ction=20 switching
context
> is a reserved term for me.
>
> W= hat=20 you are looking for is the assignment of what is called "entity
>=20 number"s: W1, W2, W3, ..
>
> These entity numbers are assigne= d by=20 connection management (NMS or
control
> plane) when it sets up t= he=20 protected connections. Both sides have to
be
> configured with t= he=20 same entity numbers, otherwise the APS protocol
will
>=20 fail.
>
> Because these entity numbers are present, one can r= e-use=20 those numbers
to
> express a priority order between Wi and Wj as= =20 specified in e.g.
G.873.1.
> See below:
>
>=20 -----------------
> [G.873.1] 8.10  Equal priority requests=20 specifies the following:
>
> -       In genera= l,=20 once a switch has been completed due to a request,
>    = =20     it will not be overridden by another request of the=20 same
priority
>         (first come, first s= erved=20 behaviour).
>
> -       When equal priority=20 requests occur simultaneously, the
conflict
>     &nbs= p;=20   is resolved in favour of the request with the lowest entity
>= ;=20 number.
>         # In bidirectional switching,= a=20 request received over the APS
> channel
>      = ;=20     with a lower entity number will always override an=20 identical
> priority
>           loc= al=20 request with a higher entity number.
>         = #=20 Equal priority requests for the same entity number from both
> &nbs= p;=20         sides of a bidirectional protection group are= =20 both
considered
>           valid, and= =20 equivalent to a received "RR" from a near-end
> processing
>= =20           standpoint.
>=20 -----------------
>
> Regards,
> Maarten
>
>= ;=20 -----Original Message-----
> From: Eric Osborne (eosborne) [mailto:= eosborne@cisco.com]
> Sent: = maandag=20 2 april 2012 12:57
> To: Maarten vissers; Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov>=20 Weingarten; mpls@ietf.org
> Su= bject:=20 RE: Comments on draft-ezy-mpls-1ton-protection-01
>
> I'm not= sure=20 that answers my question, although it may be that it does
and
> = I=20 don't understand it.
>
> I think what you're talking about is= the=20 alarm hierarchy; that is, if
I
> get both LOP and FS on the same= LSP,=20 FS 'wins'.  We have this behavior
in
> 1:1 PSC already.=20  What we're trying to sort out with 1:n is what
happens
> w= hen=20 two LSPs encounter the same failure condition.
>
> If Wx and = Wy=20 both get SF, only one of them can be protected in 1:n.
In
> orde= r to=20 decide which one we need something deterministic.=20  Talking
about
> 'priority' and 'tie-breakers' as if they w= ere=20 different makes no sense
in
> this context.  If two LSPs ar= e of=20 the same priority due to a priority
> config on a network device, t= he=20 tie-breaker will be something else.
As
> you and others have=20 suggested, we can require the nodes to rely on the
> signaled FPath= =20 value, standardizing the fact that the lower value is
alway
> of= =20 better priority.
>
> The question Greg originally raised was= =20 essentially "how do we know
what
> that priority scheme is?"=20  Our answer heretofore in the 1:n drafts has
> been "depends o= n the=20 device, and both devices have to agree" but the
more
> I look at= it=20 the more that doesn't make sense.
>
> I think what we need is= =20 something akin to what you pointed out earlier
is
> already done= in=20 MSP; lower numeric value for FPath always=20 wins.
>
>
>
>
>
> eric
>
>= ;=20 > -----Original Message-----
> > From: Maarten vissers [mailt= o:maarten.vissers@huawei.com= ]
>=20 > Sent: Monday, April 02, 2012 6:06 AM
> > To: Eric Osborne=20 (eosborne); Gregory Mirsky; zhang.fei3@zte.com.cn;
>= =20 Yaacov
> > Weingarten; mpls@ietf.org
> > Subject: RE:= =20 Comments on draft-ezy-mpls-1ton-protection-01
> >
> > H= i=20 Eric,
> >
> > The standard specifies the priority order= of=20 requests. E.g. in
G.873.1
> > (OTN linear protection,
>= =20 >
http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3D= T-REC-G.873.1-201107-
>=20 > I!!PDF-E&type=3Ditems
> <http://www.itu.int/rec/dologin_pub.asp?lang=3De&id=3D= T-
>=20 > REC-G.873.1-201107-I!!PDF-E&type=3Ditems> ) the=20 following
specification
> is
> > included:
>=20 >
> > 8.3     Request type
> > The request= =20 types that may be reflected in the APS bytes are the
> > "standa= rd"=20 types traditionally supported by protection switching for
>=20 SONET
> > and SDH. These requests reflect the highest priority=20 condition,
> command,
> > or state (see Tables 2 and 3). I= n the=20 case of unidirectional
> switching,
> > this is the highes= t=20 priority value determined from the near end
only.
> In
> &= gt;=20 bidirectional switching, the local request will be indicated only in
&= gt;=20 the
> > case where it is as high or higher than any request rece= ived=20 from
the
> far
> > end over the APS channel. In=20 bidirectional switching, when the far
end
> > request has the= =20 highest priority, the near end will signal Reverse
> >=20 Request.
> > Table 2/G.873.1 - Request/state priorities with APS= =20 protocol
> > Request/state  Priority
> > Lockout f= or=20 Protection (LoP)   1 (highest)
> > Signal Fail (SF) - prote= ction=20  2 (see 8.9)
> > Forced Switch (FS)     3
>= >=20 Signal Fail (SF) - working     4
> > Signal Degrade (S= D)=20    5
> > Manual Switch (MS)     6
> &g= t;=20 Wait-to-Restore (WTR)  7
> > Exercise (EXER)    = =20    8
> > Reverse Request (RR)   9
> > Do= Not=20 Revert (DNR)    10
> > No Request (NR)     &= nbsp;=20  11 (lowest)
> > Table 3/G.873.1 - Request/state priorities= =20 without APS protocol
> > Request/state  Priority
> &g= t;=20 Lockout for Protection (LoP)   1 (highest)
> > Forced Switc= h=20 (FS)     2
> > Signal Fail (SF)      =20 3
> > Signal Degrade (SD)    4
> > Manual Swi= tch=20 (MS)     5
> > Wait-to-Restore (WTR)  6
> &= gt;=20 Do Not Revert (DNR)    7
> > No Request (NR)   &n= bsp;=20    8 (lowest)
> >
> >
> >
> &g= t;=20 Regards,
> > Maarten
> >
> >
> >=20 -----Original Message-----
> > From: Eric Osborne (eosborne)=20 [mailto:eosborne@cisco.com]
= >=20 > Sent: maandag 2 april 2012 11:56
> > To: Maarten vissers;=20 Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov>=20 > Weingarten; mpls@ietf.org
&g= t; >=20 Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
>=20 >
> > Hi Maarten-
> >
> > How does a node k= now=20 that two requests are of equal priority?  Is
this
> > so= mehow=20 configured a priori on the MSP endpoints?
> >
> >
&g= t;=20 >
> >
> > eric
> >
> >
> >= ;=20 > -----Original Message-----
> > > From: Maarten vissers=20 [mailto:maarten.vissers@huawei.com= ]
>=20 > > Sent: Thursday, March 29, 2012 3:06 PM
> > > To: Ma= arten=20 vissers; Eric Osborne (eosborne); Gregory Mirsky;
> > > zhang.fei3@zte.com.cn; Yaacov=20 Weingarten; mpls@ietf.org
> &g= t; >=20 Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> >=20 >
> > > Below is a copy of the equal priority text in G.87= 3.1=20 (OTN linear
> > > protection):
> > >
> >= >=20 8.10  Equal priority requests
> > > In general, once a s= witch=20 has been completed due to a request, it
> will
> > not
= >=20 > > be overridden by another request of the same priority (first=20 come,
> > first
> > > served behaviour). When equal= =20 priority requests occur
> simultaneously,
> > the
> = >=20 > conflict is resolved in favour of the request with the=20 lowest
entity
> > > number. In bidirectional switching, a= =20 request received over the
APS
> > > channel with a lower e= ntity=20 number will always override an
identical
> > > priority lo= cal=20 request with a higher entity number. Equal priority
> > > req= uests=20 for the same entity number from both sides of a
> bidirectional
= >=20 > > protection group are both considered valid, and equivalent to=20 a
> > received
> > > "RR" from a near-end processing= =20 standpoint.
> > >
> > > Regards,
> > >= ;=20 Maarten
> > >
> > > -----Original Message----->=20 > > From: mpls-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org]=20 On
Behalf
> > Of
> > > Maarten vissers
> &g= t;=20 > Sent: donderdag 29 maart 2012 14:54
> > > To: Eric Osbor= ne=20 (eosborne); Gregory Mirsky;
zhang.fei3@zte.com.cn;
> = >=20 Yaacov
> > > Weingarten; mpls@ietf.org
> > > Subject= : Re:=20 [mpls] Comments on draft-ezy-mpls-1ton-protection-01
> > >>=20 > > 1:n protection in a transport network at the path layer is not= =20 a
> very
> > > common protection switching application.= This=20 is due to the fact
> that
> > 1:n
> > > protec= tion=20 requires n+1 diverse routed paths. How many of those
> >=20 diverse
> > > routed paths will be available in typical trans= port=20 networks? Not
> > many...
> > > very often two diver= se=20 routed paths is all you can get... and this
> is
> >=20 only
> > > truly guaranteed over time if the network domain i= s=20 organized as
> > separate
> > > A and a B networks.= =20 Otherwise maintenance on the network may
result
> in
> >= ;=20 > temporary rerouting of virtual links, resulting in routing W and=20 P
> > > connections over the same fiber, node or duct.
>= ;=20 > >
> > > With n>2, separate networks can not be use= d and=20 one has to find
n+1
> > > diverse routed paths through the= =20 network and guarantee that
neither
> > > maintenance=20 activities, nor network upgrades result in rerouting
of
> >=20 the
> > > virtual links so that W and P connections pass thro= ugh=20 the same
> fiber,
> > > node or duct.
> >=20 >
> > > 1:n protection has been used in SDH/SONET for=20 SDH/SONET
regenerator
> > > protection (1:7 and 1:11 syste= ms,=20 in early 90's) and for SDH line
> card
> > > protection= (end=20 of 90's).
> > >
> > > Regards,
> > >= =20 Maarten
> > >
> > > -----Original Message----->=20 > > From: mpls-bounces@ietf.org [mailto:<= A=20 href=3D"mailto:mpls-bounces@ietf.org">mpls-bounces@ietf.org]=20 On
Behalf
> > Of
> > > Eric Osborne (eosborne)>=20 > > Sent: donderdag 29 maart 2012 14:31
> > > To: Grego= ry=20 Mirsky; zhang.fei3@zte.com.cn;=20 Yaacov Weingarten;
> > > mpls@ietf.org
> > > Subject= : Re:=20 [mpls] Comments on draft-ezy-mpls-1ton-protection-01
> > >>=20 > > I still go back to my point that since only one W can ever use= =20 P,
> > there
> > > really is no such thing as 'equal= =20 priority'.  We must have a
> priority
> > > scheme= ,=20 whether it is the channel number in Fpath or whether it's
> some>=20 > > other mechanism, so that we know that Wi always beats Wj no=20 matter
> > what
> > > order the events occur in.
= >=20 > >
> > > We had initially discussed leaving the exact= =20 priority scheme to
the
> > > protection endpoints, but I s= ee=20 now that that may not work well
> across
> > >=20 vendors.
> > >
> > > I think we have a few=20 choices:
> > >
> > > 1) some sort of explicit pri= ority=20 field
> > > 2) define priority as the FPath value, lower is b= etter=20 (as Maarten
> > > points out, this is the current practice in= =20 SDH).
> > >
> > > Either one of these have costs = to=20 them.
> > >
> > > Doing #1 leaves us with a poten= tial=20 mismatch; if LER-A thinks W2
has
> > > prio1 and LER-Z thi= nks=20 W3 has prio1, sorting this out is messy,
and
> in
> > &= gt;=20 locking mode means nobody is protected until both ends converge.
>= =20 This
> > > also makes things (potentially) very dynamic which= is,=20 I think,
not
> > what
> > > we want in a protocol= that=20 has to converge in real time.
> > >
> > > Doing #= 2=20 means that if I have W1...W5 already provisioned and I
want
> &g= t;=20 to
> > > add W3.1, I need to reprovision W4 and W5, which may= =20 be
disruptive.
> > How
> > > often does this sort= of=20 thing happen in transport networks?  Is it
a
> > > re= al=20 problem?
> > >
> > >
> > >
> &g= t;=20 >
> > > eric
> > >
> > > >=20 -----Original Message-----
> > > > From: Gregory Mirsky=20 [mailto:gregory.mirsky@ericsson.com]
>=20 > > > Sent: Thursday, March 29, 2012 2:21 PM
> > > &= gt;=20 To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov>=20 > Weingarten;
> > > > mpls@ietf.org
> > > > Su= bject:=20 RE: Comments on draft-ezy-mpls-1ton-protection-01
> > >=20 >
> > > >
> > > > Hi Eric,
> > = >=20 > I agree with your logic and that current document=20 handles
scenario
> > you
> > > > present (prio= ties=20 of simulteneously failed paths are different)
> > well.
> = >=20 > But
> > > > I still am concerned with case when prior= ities=20 of Wi and Wj are
> > equal.
> > > If
> > &g= t;=20 > you think that it might present a problem, then I see=20 two
possible
> > > ways to
> > > >=20 address:
> > > > - disallow multiple LSPs being assigned e= qual=20 priority (not the
> best
> > > way);
> > > = >=20 - define tiebreaking rule(s).
> > > >
> > > &g= t;=20      Regards,
> > > >      = =20        Greg
> > > >
> > > = >=20 -----Original Message-----
> > > > From: Eric Osborne=20 (eosborne) [mailto:eosborne@cisco.com]
> > &= gt;=20 > Sent: Thursday, March 29, 2012 5:11 AM
> > > > To: Gr= egory=20 Mirsky; zhang.fei3@zte.com.cn;=20 Yaacov Weingarten;
> > > > mpls@ietf.org
> > > > Su= bject:=20 RE: Comments on draft-ezy-mpls-1ton-protection-01
> > >=20 >
> > > > Let me rewrite the messages a little bit in y= our=20 example.
Rather
> > than
> > > > SF(1,0), let'= s use=20 SF(Wi,0) or Sf(Wj,0), where Wi and Wj are the
> > LSPs
> &= gt;=20 > in
> > > > question.  And let's also say that th= e=20 priority of Wi > Wj, just
> as
> > > you
> >= ;=20 > > have done.
> > > >
> > > > I also= note=20 that setting Path=3D=3D0 means you're using locking
mode.
> >= >=20 This is
> > > > certainly a valid case, I just want to con= firm=20 that it's your
> > > intention?
> > > >
>= ;=20 > > > at t0, no failure.
> > > >
> > >= ;=20 > at t1,
> > > >   LER-A sends SF(Wi,0) to=20 LER-Z
> > > >     AND
> > > > &nb= sp;=20 LER-Z sends SF(Wj,0) to LER-Z
> > > >
> > > &g= t; at=20 t2, LER-A receives SF(Wj,0).  It ignores it, since it has
>=20 already
> > > > decided that Wi needs the protect=20 channel.
> > > >
> > > > LER-Z also receive= s=20 SF(Wi,0).  This is either exactly at t2, or
at
> >=20 t3,
> > > > shortly after t2.
> > > >
&g= t;=20 > > > LER-Z knows a priori that Wi > Wj, so LER-Z treats this= as=20 a
> > > > unidirectional locking preemption case, as in se= ction=20 3.3.3.2 of
> the
> > > > draft.  LER-Z responds= to=20 the SF(Wi,0) with NR(Wi,0).  This is
> what
> > > = >=20 3.3.3.2 describes as LER-A's behavior at t1.
> > > >
&g= t;=20 > > > In this way, both LER-A and LER-Z converge on protecting=20 Wi.
> Since
> > it
> > > is
> > > = >=20 locking, no transmission of packets takes place since neither
side
= >=20 > had
> > > > ACKd the other side's SF.
> > &g= t;=20 >
> > > > Does that reflect your question, and does it= =20 answer it?
> > > >
> > > >
> > >= ;=20 >
> > > >
> > > >
> > > >= =20 eric
> > > >
> > > > > -----Original=20 Message-----
> > > > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
>=20 > > > > Sent: Thursday, March 29, 2012 1:51 PM
> > &= gt;=20 > > To: Eric Osborne (eosborne); zhang.fei3@zte.com.cn; Yaacov>=20 > > Weingarten;
> > > > > mpls@ietf.org
> > > > &g= t;=20 Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> > &= gt;=20 > >
> > > > > Hi Eric,
> > > > >= ;=20 Below is scenario that in my view would benefit from a
>=20 tiebreaking
> > > > rule.
> > > > > Woul= d=20 appreciate your consideration and feedback whether this
is
> >= ;=20 > > realistic
> > > > > and not breaking PSC:
= >=20 > > > > - Assume that LSP P is not being used or used by work= ing=20 path
of
> > > > priority
> > > > >=20 N;
> > > > > - LER-A detects failure of working path Wi= of=20 priority M,
where
> M
> > >
> > > N,
= >=20 > > > > LER-A sends SF(1,0) to LER-Z listing Wi as Fpath;
= >=20 > > > > - almost simulteneously, at least before it receives = SF=20 from
> > LER-A,
> > > > LER-Z
> > > &= gt;=20 > detects failure of Wj that has priority M. LER-Z sends SF(1,0)
&g= t;=20 > > listing
> > > > Wj
> > > > > a= s=20 Fpath;
> > > > > - LER-Z receives SF(1,0) from LER-A an= d=20 since Priority(Wi) =3D=3D
> > > > Priority(Wj)
> >= ; >=20 > > would not change to protecting Wi path;
> > > > = >=20 - LER-A receives SF(1,0) from LER-Z and for the same reason
>=20 would
> > > keep
> > > > Wi
> > > = >=20 > as path to protect.
> > > > > Is that sequence,=20 scenario correct? Would LER-A and LER-Z
> converge
> > >= ;=20 on
> > > > > selecting one path they'd protect?
>= >=20 > > >
> > > > >    Regards,
> = >=20 > > >            Greg
> >= >=20 > >
> > > > > -----Original Message-----
> = >=20 > > > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com]
> > &= gt;=20 > > Sent: Thursday, March 29, 2012 4:38 AM
> > > > &= gt;=20 To: Gregory Mirsky; zhang.fei3@zte.com.cn; Yaacov=20 Weingarten;
> > > > > mpls@ietf.org
> > > > &g= t;=20 Subject: RE: Comments on draft-ezy-mpls-1ton-protection-01
> > &= gt;=20 > >
> > > > >
> > > > > > EO= #=20  I would argue that one should not have LSPs of the
"same
>= >=20 > > > priority".
> > > > > > There must be = a=20 tiebreaker that can handle all possible
> > conflicts,
> &= gt;=20 > > no
> > > > > > matter what order or how ma= ny=20 failures.  Once there is a
> > > > deterministic
&= gt;=20 > > > > > mechanism for all cases, it means that all LSPs = are=20 of
> different
> > > > > priority.
> > &= gt;=20 > > >
> > > > > > GIM>> Tiebreaking w= ould=20 be used only in case of simulteneous
> > > failure
> &g= t;=20 > > > of
> > > > > > two working paths of e= qual=20 priority. Otherwise, equal
priority
> > > would
> &g= t;=20 > > > not
> > > > > > preempt one that is=20 already is using the protection path,
i.e.
> > > FIFO
&= gt;=20 > > > > will
> > > > > > fully work in t= his=20 case.
> > > > >
> > > > >
> >= ;=20 > > > I think the behavior you describe is more about SMP than=20 1:n.
> In
> > > 1:n
> > > > we'd
>= >=20 > > > always made the assumption that, in a given protection=20 domain,
> > only
> > > a
> > > > >= =20 single W can be protected at a time.  To do otherwise (say, W1
&g= t;=20 and
> > > W2
> > > > > using P) is not poss= ible=20 using PSC signaling since we can only
> > > > indicate=20 a
> > > > > single LSP in the FPath field.
> >= >=20 > >
> > > > > Nothing precludes multiple protecti= on=20 domains from using the
> same
> > > > > underlyin= g=20 link and/or same endpoints, but that's a network
> design
> &= gt;=20 > > > consideration.
> > > > >
> > &g= t;=20 > >
> > > > >
> > > > >
>= >=20 > > > eric
> > >=20 _______________________________________________
> > > mpls ma= iling=20 list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> &g= t; >=20 _______________________________________________
> > > mpls ma= iling=20 list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
>=20 >

--_000_FE60A4E52763E84B935532D7D9294FF135510FF47FEUSAACMS0715e_-- From wyaacov@gmail.com Wed Apr 4 05:39:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4CA21F864F for ; Wed, 4 Apr 2012 05:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-VdvuEnT2AH for ; Wed, 4 Apr 2012 05:39:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EF21F867F for ; Wed, 4 Apr 2012 05:39:05 -0700 (PDT) Received: by qcsq13 with SMTP id q13so143715qcs.31 for ; Wed, 04 Apr 2012 05:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vly2NGSAFaUXyX8mV6U6rCimHv/Ksg/wX4u3i8AyA5s=; b=TTXqrXPapyoeHzKSmcdRQZ/VJtCu7vGElqcXFpP3UB12XRaJcFrcJcAtilDAQDXDRq vqZoM2wZRX/bQksSu/hmZRO6zR2PsqWsEm++HrgerOkFk5aDLKqFOZ2kraqcIaLp+8KF KvtpQrtTytY6DCVwXZkF8WdYNlRw/jVmo983Td6QcCp6onwvjKKBJ6f/+SnHFrMwvves EV4v++pMI8YYL24nyWYtvg6j5iQaon2vIH5ZzRyzM1WWQpZlGpj7fmcggU6cWqNPrvXo Ilcs/5l8kT3BI+gbA8JoQ5kPolqeXTGsxU0qkoBjyF0QUUacpW+5iZWW/rPaQI1SfrHW NowQ== MIME-Version: 1.0 Received: by 10.224.214.66 with SMTP id gz2mr21056318qab.22.1333543145392; Wed, 04 Apr 2012 05:39:05 -0700 (PDT) Received: by 10.229.28.80 with HTTP; Wed, 4 Apr 2012 05:39:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Apr 2012 15:39:05 +0300 Message-ID: From: Yaacov Weingarten To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3005dcf679498204bcd9b5f3 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 12:39:07 -0000 --20cf3005dcf679498204bcd9b5f3 Content-Type: text/plain; charset=ISO-8859-1 Greg, hi I see problems with the suggestion that each endpoint include the priority of the working path in the PSC message - 1. If both endpoints are coordinated on the priority of the different working paths then there is no difference between adding the priority to the message or letting the endpoints make the decision based on their configuration. However, if there is a misconfiguration such that the priority for Wj is different at LER-A and LER-Z then including the priority in the message could cause problems. Let's consider the scenario that was described earlier in this thread - where one endpoint is reporting a SF on Wj and the other endpoint is reporting a SF on Wk. We may end up with a conflict between the endpoints as to which working path is being protected at the point where a decision needs to be made! 2. PSC, as defined in RFC6378, is a simple protocol that has a few idiosyncrasies - one of which is that the messages are constantly being sent, adding the priority TLV is just additional chatter that will be using up bandwidth on the protection path. 3. Another characteristic of PSC is that each endpoint continues to report in the FPath field the identity of the working path that is currently triggering that endpoint. This may mean, e.g. in the case of unidirectional faults or operator commands, that the FPath of the messages from the two endpoints may be different, e.g. LER-A may be sending SF(j,k) while LER-Z is sending SF(k,k), and the question is whether the priority is for the FPath or the Path field? 4. Keeping in mind that 1:n protection domain is characterized by all n+1 paths having the same endpoints, I feel that dealing with the priorities at the configuration level is just simpler, and defining the tiebreaker based on the FPath index is rather straightforward. For your consideration, yaacov On Tue, Apr 3, 2012 at 11:13 PM, Gregory Mirsky wrote: > ** > Dear Yaacov, et al., > Path Identifier is a reference to one of N LSPs that share the protection > LSP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear > Protection PSC message from PSC message in 1:n?) need to find failed LSP > priority. I think it might be reasonable to signal priority of failed path > along with the Failed Path Index in a TLV, hence making it mandatory in > PSCv.2. > > Regards, > Greg > > --20cf3005dcf679498204bcd9b5f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Greg, hi

I see problems w= ith the suggestion that each endpoint include the priority of the working p= ath in the PSC message -

1. If both endpoints are = coordinated on the priority of the different working paths then there is no= difference between adding the priority to the message or letting the endpo= ints make the decision based on their configuration. =A0However, if there i= s a misconfiguration such that the priority for Wj is different at LER-A an= d LER-Z then including the priority in the message could cause problems. = =A0Let's consider the scenario that was described earlier in this threa= d - where one endpoint is reporting a SF on Wj and the other endpoint is re= porting a SF on Wk. We may end up with a conflict between the endpoints as = to which working path is being protected at the point where a decision need= s to be made!

2. PSC, as defined in RFC6378, is a simple protocol tha= t has a few=A0idiosyncrasies - one of which is that the messages are consta= ntly being sent, adding the priority TLV is just additional chatter that wi= ll be using up bandwidth on the protection path.

3. Another characteristic of PSC is that each endpoint = continues to report in the FPath field the identity of the working path tha= t is currently triggering that endpoint. =A0This may mean, e.g. in the case= of unidirectional faults or operator commands, =A0that the FPath of the me= ssages from the two endpoints may be different, e.g. LER-A may be sending S= F(j,k) while LER-Z is sending SF(k,k), and the question is whether the prio= rity is for the FPath or the Path field?

4. Keeping in mind that 1:n protection domain is charac= terized =A0by all n+1 paths having the same endpoints, I feel that dealing = with the priorities at the configuration level is just simpler, and definin= g the tiebreaker based on the FPath index is rather straightforward.

For your consideration,
yaacov


On Tue, Apr 3, 2012 at 11:13 PM, Greg= ory Mirsky <gregory.mirsky@ericsson.com> wrote:
Dear Yaacov, et al.,
Path Identifier is a reference to=A0one of N=A0LSPs=20 that share the protection LSP. LER that recieves PSCv.2 (do we need=A0acron= ym=20 to differentiate Linear Protection PSC message from PSC message in 1:n?) ne= ed to=20 find failed LSP priority. I think it might be reasonable to signal priority= of=20 failed path along with the Failed Path Index in a TLV, hence making it mand= atory=20 in PSCv.2.
=A0
=A0=A0=A0 Regards,
=A0=A0=A0=A0=A0=A0=A0 Greg



--20cf3005dcf679498204bcd9b5f3-- From yshen@juniper.net Wed Apr 4 10:13:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B53121F87EB for ; Wed, 4 Apr 2012 10:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K8I7hsVIfCI for ; Wed, 4 Apr 2012 10:13:50 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 8104021F87EF for ; Wed, 4 Apr 2012 10:13:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKT3yBH2CZk4CrML1BAS8Ak6wZeTL+2ywR@postini.com; Wed, 04 Apr 2012 10:13:31 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Apr 2012 10:11:43 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Apr 2012 10:11:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 4 Apr 2012 13:11:40 -0400 From: Yimin Shen To: "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Date: Wed, 4 Apr 2012 13:11:38 -0400 Thread-Topic: comments on draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac0Shf8u1K3w2DeITyaXdtWAFD/O9Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] comments on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 17:13:51 -0000 Huaimo,=20 As I commented during your presentation, the current draft only supports 1:= 1 protection. IOW, in order to protect X primary PEs, you would need X dedi= cated backup PEs. Therefore, from the perspective of cost efficiency, the d= raft may need to consider 1:N protection and "dual-role" PE (i.e. a primary= PE also serves as a backup PE for another primary PE). OTOH, even with the current 1:1 protection, I see a more fundamental issue = with the following type of topology, where two primary PEs (i.e. their path= s) share the same penultimate hop router, and the paths to their backup PEs= share the same downstream link from the penultimate hop router.=20 Please see an example below. Assume a CE is dual-homed to PE-prim-1 and PE-= back-1, and another CE is dual-homed to PE-prim-2 and PE-back-2 (not shown = in the picture). If PE-prim-1 fails, P1 will turn on traffic towards P2, ho= ping the traffic to reach PE-back-1. However, not only PE-back-1 will recei= ve the traffic, but also PE-back-2 as well. This is because the path P1 -> = P2 -> PE-back-2 shares the link P1-P2 with the path P1 -> P2 ->PE-back-1. = Hence, the CE connected to PE-prim-2 and PE-back-2 will receive duplicate t= raffic from both PEs at the same time. I think the draft needs to address t= his kind problem. PE-in ---------- P1 ---------- PE-prim-1 | \---------- PE-prim-2 | | P2 ---------- PE-back-1 \---------- PE-back-2 Thanks, -Yimin Shen Juniper Networks From gregory.mirsky@ericsson.com Wed Apr 4 18:07:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791F211E8086 for ; Wed, 4 Apr 2012 18:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8lsQDmPCEXz for ; Wed, 4 Apr 2012 18:07:56 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7959011E8074 for ; Wed, 4 Apr 2012 18:07:56 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3517s48012035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Apr 2012 20:07:54 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 4 Apr 2012 21:07:54 -0400 From: Gregory Mirsky To: Yaacov Weingarten , "mpls@ietf.org" Date: Wed, 4 Apr 2012 21:07:53 -0400 Thread-Topic: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 Thread-Index: Ac0SX/FY1iZ6XVpvSjOOAIllcKrAVgAZOczw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF135510FFA4DEUSAACMS0715e_" MIME-Version: 1.0 Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 01:07:57 -0000 --_000_FE60A4E52763E84B935532D7D9294FF135510FFA4DEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaacov, thank you for your detailed analysis. I agree with your arguments but would= note that Path priority has to be checked first in the scenario we're disc= using - simultaneous detection of bi-directional failure. PSC format v.2 im= plicitly, by FPath, refers to priority of a failed path (let's call it FPri= ority). And without explicitly signaling FPriority LER might end up in conf= used state if priorities of protected paths were misconfigured. I'm proposi= ng to make signaling of FPriority explicit to expedite tiebraking and help = to troubleshoot misconfiguration. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Yaa= cov Weingarten Sent: Wednesday, April 04, 2012 5:39 AM To: mpls@ietf.org Subject: Re: [mpls] Comments on draft-ezy-mpls-1ton-protection-01 Greg, hi I see problems with the suggestion that each endpoint include the priority = of the working path in the PSC message - 1. If both endpoints are coordinated on the priority of the different worki= ng paths then there is no difference between adding the priority to the mes= sage or letting the endpoints make the decision based on their configuratio= n. However, if there is a misconfiguration such that the priority for Wj i= s different at LER-A and LER-Z then including the priority in the message c= ould cause problems. Let's consider the scenario that was described earlie= r in this thread - where one endpoint is reporting a SF on Wj and the other= endpoint is reporting a SF on Wk. We may end up with a conflict between th= e endpoints as to which working path is being protected at the point where = a decision needs to be made! 2. PSC, as defined in RFC6378, is a simple protocol that has a few idiosync= rasies - one of which is that the messages are constantly being sent, addin= g the priority TLV is just additional chatter that will be using up bandwid= th on the protection path. 3. Another characteristic of PSC is that each endpoint continues to report = in the FPath field the identity of the working path that is currently trigg= ering that endpoint. This may mean, e.g. in the case of unidirectional fau= lts or operator commands, that the FPath of the messages from the two endp= oints may be different, e.g. LER-A may be sending SF(j,k) while LER-Z is se= nding SF(k,k), and the question is whether the priority is for the FPath or= the Path field? 4. Keeping in mind that 1:n protection domain is characterized by all n+1 = paths having the same endpoints, I feel that dealing with the priorities at= the configuration level is just simpler, and defining the tiebreaker based= on the FPath index is rather straightforward. For your consideration, yaacov On Tue, Apr 3, 2012 at 11:13 PM, Gregory Mirsky > wrote: Dear Yaacov, et al., Path Identifier is a reference to one of N LSPs that share the protection L= SP. LER that recieves PSCv.2 (do we need acronym to differentiate Linear Pr= otection PSC message from PSC message in 1:n?) need to find failed LSP prio= rity. I think it might be reasonable to signal priority of failed path alon= g with the Failed Path Index in a TLV, hence making it mandatory in PSCv.2. Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF135510FFA4DEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yaacov,
thank you for your detailed analysis. I agree with= your=20 arguments but would note that Path priority has to be checked first in the= =20 scenario we're discusing - simultaneous detection of bi-directional failure= . PSC=20 format v.2 implicitly, by FPath, refers to priority of a failed path (= let's=20 call it FPriority). And without explicitly signaling FPriority LER might en= d up=20 in confused state if priorities of protected paths were misconfigured. I'm= =20 proposing to make signaling of FPriority explicit to expedite tiebraking an= d=20 help to troubleshoot misconfiguration.
 
  &n= bsp; Regards,
        Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Yaacov=20 Weingarten
Sent: Wednesday, April 04, 2012 5:39 AM
To:= =20 mpls@ietf.org
Subject: Re: [mpls] Comments on=20 draft-ezy-mpls-1ton-protection-01


Greg, hi

I see problems with the suggestion that each endpoint include the prio= rity=20 of the working path in the PSC message -

1. If both endpoints are coordinated on the priority of the different= =20 working paths then there is no difference between adding the priority to th= e=20 message or letting the endpoints make the decision based on their configura= tion.=20  However, if there is a misconfiguration such that the priority for Wj= is=20 different at LER-A and LER-Z then including the priority in the message cou= ld=20 cause problems.  Let's consider the scenario that was described earlie= r in=20 this thread - where one endpoint is reporting a SF on Wj and the other endp= oint=20 is reporting a SF on Wk. We may end up with a conflict between the endpoint= s as=20 to which working path is being protected at the point where a decision need= s to=20 be made!

2. PSC, as defined in RFC6378, is a simple protocol that has a=20 few idiosyncrasies - one of which is that the messages are constantly = being=20 sent, adding the priority TLV is just additional chatter that will be using= up=20 bandwidth on the protection path.

3. Another characteristic of PSC is that each endpoint continues to re= port=20 in the FPath field the identity of the working path that is currently trigg= ering=20 that endpoint.  This may mean, e.g. in the case of unidirectional faul= ts or=20 operator commands,  that the FPath of the messages from the two endpoi= nts=20 may be different, e.g. LER-A may be sending SF(j,k) while LER-Z is sending= =20 SF(k,k), and the question is whether the priority is for the FPath or the P= ath=20 field?

4. Keeping in mind that 1:n protection domain is characterized  b= y all=20 n+1 paths having the same endpoints, I feel that dealing with the prioritie= s at=20 the configuration level is just simpler, and defining the tiebreaker based = on=20 the FPath index is rather straightforward.

For your consideration,
yaacov


On Tue, Apr 3, 2012 at 11:13 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:
Dear= Yaacov, et=20 al.,
Path= Identifier=20 is a reference to one of N LSPs that share the protection LSP. = LER=20 that recieves PSCv.2 (do we need acronym to differentiate Linear=20 Protection PSC message from PSC message in 1:n?) need to find failed LSP= =20 priority. I think it might be reasonable to signal priority of failed pat= h=20 along with the Failed Path Index in a TLV, hence making it mandatory in=20 PSCv.2.
 
    Regards,
      &nb= sp; Greg



--_000_FE60A4E52763E84B935532D7D9294FF135510FFA4DEUSAACMS0715e_-- From rajiva@cisco.com Thu Apr 5 12:45:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920BE21F8674 for ; Thu, 5 Apr 2012 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGQchrERyBKR for ; Thu, 5 Apr 2012 12:45:52 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8AADE21F8680 for ; Thu, 5 Apr 2012 12:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=47948; q=dns/txt; s=iport; t=1333655152; x=1334864752; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=YdekPOhULvZPGknLJP/Ka018FNwhNTwQDxq6cESBeMk=; b=UunlwqaWoACJ//tUoSL6b3nLrMco8dj2WhAWR26KqkPmlDxoJGz6GtAn sri19gbp8RDV2GaSdkHjpo74GHFI34y+mRp/plwJrC+qOi0EFh9Q43JC9 OEmQUAq3gUEDLb1Z/uVQFZkKfE/t/nHu6ZM98JyoDZwDSz77ZwwMs8FGw 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEP1fU+rRDoI/2dsb2JhbABFuHOBB4IJAQEBAwEBAQEPAQcBFQotBQIEBAMFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQTCAESB4dnBAELmmifZIsohE9jBIhZgmOLQIVLh2+BaYMFgTYCBQ X-IronPort-AV: E=Sophos;i="4.75,377,1330905600"; d="scan'208";a="39253359" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 05 Apr 2012 19:45:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q35Jjpbd011607; Thu, 5 Apr 2012 19:45:51 GMT Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 12:45:51 -0700 Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Apr 2012 14:45:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Apr 2012 14:45:42 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07E3777A@XMB-RCD-111.cisco.com> In-Reply-To: <5DF53972F7E9134782DCE51624466FE50AD5A09189@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3gBWT9FgAIW35sA= References: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5A09189@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> From: "Rajiv Asati (rajiva)" To: "Aissaoui, Mustapha (Mustapha)" X-OriginalArrivalTime: 05 Apr 2012 19:45:44.0445 (UTC) FILETIME=[B09E8AD0:01CD1364] Cc: mpls@ietf.org Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:45:55 -0000 Hi Mustapha, Please see inline, > Could you provide in details how you believe the presence of duplicate link- > local addresses from two neighbouring LSRs can cause blackhole of traffic? =09 R1--R2----R3---R4----"x" \-----R5-----------"y" R2 has a path via R3 to "x". Say, routing next-hop =3D LLAx. R3 and R5 use the same LLA (=3DLLAx) towards R2. =20 Relying on just RFC5036 section 2.7 that describes the next-hop/label resolution using ADDRESS message and says nothing about Hello Adjacency, R2 may map LLAx to R5 and use R5's label while forwarding to R3. This would result in blackholing of the traffic.=20 http://tools.ietf.org/html/rfc5036#section-2.7 =09 2.7. LDP Identifiers and Next Hop Addresses // forwarding. To retrieve the label, the LSR must be able to map the next hop address for the prefix to an LDP Identifier. ....=20 To enable LSRs to map between a peer LDP Identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages. // Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Monday, April 02, 2012 11:20 PM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org; Shah, Himanshu > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) >=20 > Hi Rajiv, > Could you provide in details how you believe the presence of duplicate link- > local addresses from two neighbouring LSRs can cause blackhole of traffic? >=20 > What you describe in Section 8 is already how implementations of RFC 5036 > operate. Before you can resolve a FEC to a link, you have to find out the > outgoing interface and next-hop of that FEC prefix in the routing table. Then > you need to find the LSR-id which advertised that next-hop address as its local > address and that there is a hello adjacency to that LSR-id over that interface. In > the case of a dual-stack inteface, you just need to find a link Hello adjacency > over that interface, it does not have to be an IPv6 adjacency, to resolve an IPv6 > FEC. >=20 > Because LDP follows routing, you cannot blackhole traffic when overalpping > link-local addresses exist to different LDP peers over two different interfaces or > subnets. If overlapping occurs over the same subnet, then neighbour discovery > will detect it and will shutdown IPv6 forwarding over that interface. >=20 > Again, there is no relationship of FEC resolution to a link and the type of the > control plane adjacency. You just need to have an adjacency. >=20 > Regards, > Mustapha. >=20 > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Sunday, April 01, 2012 6:20 AM > To: Shah, Himanshu > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) >=20 > Hi Himanshu, >=20 > Appreciate your question. There are at least two benefits for sending > IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack > interface if enabled with both LDP IPv4 and LDP IPv6: >=20 > 1. Discovering v4 or/and v6 transport that the peer is willing to use for > bootstrapping the subsequent TCP session (and resorting to using the alternate > transport if the preferred one failed) > Similar to that of happy eyeball (unless hardcoded or got into collision)! >=20 > 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as the > routing next-hops > Please see section 8 for more details > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 >=20 > While it may be tempting to maintain only one hello adj (IPv4, say) (that got > used to establish the subsequent (IPv4, say) TCP/LDP session) and let go of the > other hello adj (IPv6, say) that didn't get used, it could cause traffic blackholing > (due to missing #2 above) for packets going on LSPv6. >=20 > Does this clarify? >=20 > Cheers, > Rajiv >=20 >=20 > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Wednesday, March 28, 2012 4:06 PM > > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > I second the same concern and fail to understand the rationale to > bypass the > > available > > tool (capacity negotiation). > > Thanks, > > himanshu > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Wednesday, March 28, 2012 3:56 PM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > I am afraid we are not making progress on the technical questions I > raised on > > this draft. > > > > For the benefit of everyone else on the mailing list, I am going to > state the > > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. > This > > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) > which can be > > resolved in the datapath over a given link based on the type of the > control > > plane adjacency (IPv4 or IPv6) established over that link. This > coupling of FEC > > resolution to the type of control plane adjacency is not correct and > breaks so > > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC > type between > > peers is independent of the adjacency established. > > > > In addition, this proposal now means that we need 2 link Hello > adjacencies over > > each link and 2 targeted Hello adjacencies between any two LSR nodes. > This is > > not good from a scaling perspective while it provides no gain. > > > > In an earlier exchange on this thread, we discussed the need for > introducing > > per Hello adjacency capability negotiation to address the probem of > which FEC > > types can be resolved over a given link adjacency. That is the correct > approach > > to the problem and we should keep the behaviour of RFC 5036 as is, > that is an > > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an > IPv6 link > > adjacency will bootstrap an IPv6 LDP session. There is no need or > value for two > > link Hellos associating with the same IPv4 or IPv6 LDP session. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Monday, March 12, 2012 12:25 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the discussion. Please see inline, > > > > 1. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > > > 2. > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > It is not about the FEC. It is about the LSP, and rightfully so. > > > > Hopefully, answering this Q will help us - If there are 3 links (LDP > > enabled) between two LSRs and only two have hello adj leading to the > working > > LDP session, then would the LSRs use the 3rd link (which doesn't have > valid > > hello adj) for MPLS packet forwarding? > > > > - If your answer is Yes, then we have a fundamental disagreement > independent > > of LDP IPv6. > > - If the answer is No, then that's inline with what's described in the > last para of > > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > > Perhaps, the text needs a bit of rephrasing, so please feel > free to suggest. > > > > The above has no bearing on FEC type e.g. IPv4 packet being sent over > > LSPv6 or vice versa. > > > > Hence, we leave the text as-it-is. > > > > > > 3. > > > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > Removing last paragraph of section 2.5.2 from RFC 5036 ? > > > > That would fundamentally break RFC5036. > > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. > > > > Correct and that's because each LSR uses the same LDP Identifier and > qualifies > > for the point 1 of section 2.5.2 in RFC5036, which suggests to not > establish a > > new session if there is already one existing using the same LDP > Identifier: > > > > // > > 1. If LSR1 does not already have an LDP session for the exchange > > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP > // > > > > > > > It becomes an issue of association of multiple Hello adjacencies > with > > > a single TCP connection. > > > > And it is not an issue thanks to the last para of section 2.5.2. We > can NOT afford > > to remove it. > > > > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. > > > > > > 4. > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > That's incorrect. As you know, PW-FEC, as per RFC5036, already > requires > > 'extended/targetted hello adj', not 'basic hello adj' with the peer > before > > exchanging PW-FECs with that peer. > > > > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 > is > > enabled on an interface. This is already implicit in RFC5036. > > And if the interface is a dual-stack interface, then the behavior > shouldn't > > change. > > > > > > 5. > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. > > > > Well, RFC5036 (LDP version 1) prescribes using a single session for > exchanging > > FEC-label bindings for various FEC types. > > > > We could work on version 2 to move away from that intention e.g. allow > using > > more than one session between two LSRs. > > > > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > > vice-versa. There is no relationship whatsoever between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > > exchanged, as permitted. > > We are in agreement here. > > > > 6. > > Given the lack of response for #6, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 7. > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > > Please see my response to #4. Nonetheless, this is moot, as it is a > MAY, and is > > local to the LSR. > > FWIW, this point has been beaten to death last yr, and I would urge > you to > > check the discussion on the mailing list from last yr. > > > > 8. > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > If the node still receives the unsupported FEC or address type, then > it indicates > > that the peer has a bug, and it should follow the behavior specified > in RFC5036 > > e.g. declare a fatal error. > > > > This is orthogonal to capability or FEC filter, since the assumption > here is that > > an LSR is willing to send/receive FEC-label bindings for both IPv4 and > IPv6 and > > more. The point is that the loophole that has existed all along is > closed when an > > LSR gets upgraded with the code compliant with this specification. > > > > 9. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 10. > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > You do make a good point about us not changing the LDP protocol > version, so, it > > is not a new protocol, and I agree. > > I will consider to change GTSM to optional (MAY), subjected to > Carlos's opinion. > > > > We will revisit it if/when the consensus suggests otherwise prior to > RFC > > publication. > > We can close this point as well. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Friday, March 02, 2012 1:09 AM > > > To: Rajiv Asati (rajiva) > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Rajiv, > > > See some follow-up inline. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > > Sent: Wednesday, February 29, 2012 10:28 PM > > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > > > > > Thanks for the review of the document and the feedback. It is never > > too late. > > > :) Sorry about the delay in getting back to you. > > > > > > Please see inline, > > > > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > Yes, they were discussed in the past and closed. > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > No. > > > > > > While it is a common practice to assign a host route to the loopback > > interface, > > > and it is a common practice to use loopback interface as the > next-hop, > > we > > > must not assume the common practice to be the norm for the protocol. > > In > > > fact, there is NO technical argument against using the non-host > route > > on a > > > loopback interface. > > > > > > In fact, almost every implementation allows the next-hop to be a > > non-host > > > route, and I am aware of at least one implementation that allows LDP > > to > > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that > if > > hello adj > > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > > forwarding on that interface. So, if IPv6 hello adj failed, then > stop > > the IPv6 > > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > > blindly > > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > > > // > > > when it receives a Hello that matches the adjacency. If the > timer > > > expires without receipt of a matching Hello from the peer, LDP > > > concludes that the peer no longer wishes to label switch using > that > > > label space for that link (or target, in the case of Targeted > > Hellos) > > > or that the peer has failed. The LSR then deletes the Hello // > > > > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > > > I agree. It doesn't have anything to do with the address family, but > > it > > > becomes restrictive when having to accommodate transport of two > > different > > > address families (IPv4 and IPv6). Pls see more details on this later > > on. > > > > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > That's not correct (and the implementation is in violation of > > RFC5036). > > > > > > We had good discussion on this early on. In fact, we had an editor's > > note on > > > this in initial versions of this document to solicit discussion on > > that. > > > > > > The last para of section 2.5.2, as stated, would result in a > > particular IP address > > > (1.1.1.1, say) being encoded in the transport address in both > > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > > (which is > > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > > from > > > carrying IPv6 transport address (or IPv4 hello from carrying > > > IPv4 transport address). It would not make sense. > > > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > > address > > > and vice versa. It wouldn't make sense and would be incorrect. > > > > > > That's why the change was needed. > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. It becomes an issue of association of multiple > > Hello > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > We thought so too, but we uncovered various corner cases in which > this > > > becomes problematic, not to mention that the indeterminism it would > > bring > > > into the picture. The easiest was to maintain hello adj per > > address-family per > > > peer. > > > > > > For ex, consider three LDP enabled interfaces between R1 and R2, > where > > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > > maintain only > > > single adj, then they would have hello adj of one transport (v6, > say) > > on dual- > > > stack interfaces, and another transport (v4, > > > say) on 3rd interface. > > > > > > Hello adj is tightly coupled with the functional LDP peering. If > (the > > > last) hello adj is lost, then LDP peering must be brought down. > > > Additionally, if hello adj is gone from an interface, then LDP > should > > prohibit > > > MPLS forwarding from using that interface. > > > > > > Another way to think about it is - if IPv4 stops functioning on an > > interface, but > > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > > penalized. > > > And vice versa. > > > > > > Having separate hello adj maintenance is much cleaner/simpler and > > provides > > > deterministic behavior. > > > > > > Nonetheless, an implementation could choose to optimize, if needed, > to > > > keep both address-family related info in a single adjacency > structure, > > but this > > > is all implementation specific. :) > > > > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > Good point, but this is a different problem. It is not about the > > sequence > > > (which was ok if IPv4 hellow as carrying two IPv4 transport > > addresses). > > > > > > The problem is that allowing IPv4 based "discovery" to suggest an > IPv6 > > > transport address is fundamentally a wrong approach, IMO. How would > > IPv4 > > > know that IPv6 transport is even functional (and vice versa). IPv4 > > based > > > discovery should suggest IPv4 transport, and IPv6 based discovery > > should > > > suggest IPv6 transport. > > > > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. BGP allows the exchage of IPv4 prefixes over an > IPv6 > > > connection and vice-versa. There is no relationship whatsoever > between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > We need the address-family awareness in peer hello adjacency/s, > > whether it > > > is a kept in a single adj structure or not. > > > > > > Loosing the AFI awareness leads up the other problems that I > mentioned > > > earlier. > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > It is MAY. :) > > > It was changed to MAY based on the exhaustive discussion on mailing > > list in > > > 2011 for us to move forward. > > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > different protocol. > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > We initially thought so too, until we discovered the following very > > explicitly in > > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > > > // > > > Section 3.5.5.1 - > > > If an LSR does not support the Address Family specified in the > Address > > List > > > TLV, it SHOULD send an Unsupported Address Family Notification to > its > > LDP > > > signaling an error and abort processing the message. > > > > > > Section 3.4.1.1 - > > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > > Address > > > Family it does not support, it SHOULD stop decoding the FEC TLV, > abort > > > processing the message containing the TLV, and send an "Unsupported > > > Address Family" Notification message to its LDP peer signaling an > > error. > > > // > > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > Because it is native in IPv6 to allow for link-local addresses that > > IPv4 never > > > allowed. > > > So, what was an anomaly with IPv4 is now a standard behavior with > > IPv6, > > > hence, that verbiage. > > > > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > We posed the Q about GTSM being the default or not during IETF 80, > and > > > there were 10-yes and 0-no (mostly from operators) Pls see the > > minutes, > > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > > > Cheers, > > > Rajiv > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Aissaoui, Mustapha (Mustapha) > > > > Sent: Monday, February 06, 2012 3:21 PM > > > > To: Shane Amante > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Shane, > > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > > LDP > > > session > > > > from a peer which is identified by the LDP identifier tuple > {LSR-id, > > > label-space- > > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > > different label > > > > spaces, then they must use two different Hello adjacencies and LDP > > > sessions for > > > > that. Also, if an implementation supports virtualization of LDP, > > then > > > a different > > > > LDP identifier altogether can be used to establish a separate LDP > > > session. Other > > > > than that, there is no relation between the type of adjacency and > > the > > > FEC which > > > > are carried. For example, the same LDP Hello Adjacency and LDP > > session > > > are > > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > > between > > > two > > > > directly connected peers. > > > > > > > > As far as I know BGP is not very different. It offers the ability > to > > > carry IPv4 NLRI > > > > over a IPv6 session and vice versa. > > > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > > IPv4 > > > on an IPv4 > > > > session between two LSRs, then we should consider extending RFC > > 5036 > > > to > > > > allow for two different LSR-id values sharing the same global > label > > > space. This > > > > way, we can have separate Hello adjacency and LDP session and it > is > > up > > > to the > > > > user to assign which FEC type is allowed on which LDP session. > This > > is > > > a new > > > > work item but in my view much cleaner and backward compatible with > > RFC > > > > 5036 than to try to tie the address family to the type of Hello > > > adjacency. > > > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > > Hello > > > > adjacency but a single shared LDP session. It is not exactly what > > you > > > are asking > > > > for. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > -----Original Message----- > > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > > Sent: Friday, February 03, 2012 11:32 PM > > > > To: Aissaoui, Mustapha (Mustapha) > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Mustapha, > > > > > > > > I am not an author, but I do want to provide some operational > input > > on > > > some of > > > > your comments. Specifically, I get the sense from several of your > > > comments -- > > > > actually, moreso from #3 -- that you are opposed to maintaining > > > separate LDP > > > > Hello and/or Session Adjacencies: 1 for each address family. (If > my > > > impression > > > > is incorrect I apologize). > > > > > > > > I actually *do* want to have separate LDP Hello and Session > > > adjacencies: one > > > > per address family, at least at this point in time. I'm concerned > > > about > > > > [operational] issues that may develop in, for example, v6 > affecting > > > the > > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > > one > > > more > > > > concrete example, 6man/v6ops are only right now working on > improving > > > the > > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > > areas where > > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > > problems in v6 > > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > > FWIW, there has > > > > already been a precedent here wrt BGP where there it maintains > > > separate > > > > neighbors/sessions for each address family, so why aren't we doing > > the > > > same > > > > thing for LDP? > > > > > > > > Ultimately, having separate sessions over-the-wire is much more > > > intuitive to > > > > operators in lots of cases where they may expect that a > > configuration > > > change > > > > or bugs they /think/ are only going to affect one address family, > > > really do only > > > > affect one address family. Besides, LDP Hello & Sessions timers, > > when > > > set to > > > > default, are extremely relaxed (order of several seconds), so the > > > burden on > > > > implementations to maintain separate sessions should be miniscule. > > > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > > over the > > > > wire to avoid "fate sharing". Only when an operator chooses to > > > explicitly > > > > configure their device to have hellos and sessions share fate > should > > > the device > > > > do so. > > > > > > > > Just my $0.02, > > > > > > > > -shane > > > > > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > > Dear authors, > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > > > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From venkat.mahalingams@gmail.com Mon Apr 2 22:42:07 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA8521F8570 for ; Mon, 2 Apr 2012 22:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2JTt3-djXLW for ; Mon, 2 Apr 2012 22:42:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF0B21F8599 for ; Mon, 2 Apr 2012 22:42:05 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2562565vbb.31 for ; Mon, 02 Apr 2012 22:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gywvmb6+7wUdFiPh3qzHIvH6Coh8/4WAYKiSFBtlX2Y=; b=zV6GXlTVeBGnBsQtHQfMD+pSMOf36XB+D8WRcmWsk3nQpthnYMR16vQXo2us92Kebw XdeH+/muKPDDZV/Iq9k55AajvIhtRVccCT/wk9/d8qc09ZJpnUTLC3EyG3zL1yJkUqQH nbON6nS6CUoOfwy4VGL3pSeggtszTiBTDzTynG9tcAV2tQW9zn3/kO11fIiDzwwNk/MM 25aui4kTiKHtNRQoSUj8FGIxPiOcP47CswvWz5in9qES8o8xJtJVrKmv9GUtae5o7XKF ddNserPQ20tU8y2ZWbNgFtCZ8oxV1Reh9Gu0yiCxIkUp737HpIu2Xq8E5uumowIixohf UU9g== MIME-Version: 1.0 Received: by 10.52.22.8 with SMTP id z8mr4554805vde.5.1333431725397; Mon, 02 Apr 2012 22:42:05 -0700 (PDT) Received: by 10.220.1.15 with HTTP; Mon, 2 Apr 2012 22:42:05 -0700 (PDT) In-Reply-To: <32CB7A1F0806AB4688CE3F22C29DAC8704179617@EXRAD5.ad.rad.co.il> References: <32CB7A1F0806AB4688CE3F22C29DAC8704179617@EXRAD5.ad.rad.co.il> Date: Mon, 2 Apr 2012 22:42:05 -0700 Message-ID: From: Venkatesan Mahalingam To: Muly Ilan Content-Type: multipart/alternative; boundary=20cf3071d0c453181004bcbfc49a X-Mailman-Approved-At: Fri, 06 Apr 2012 10:46:23 -0700 Cc: mpls@ietf.org, "thomas.nadeau@ca.com" Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-te-mib-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 05:42:07 -0000 --20cf3071d0c453181004bcbfc49a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Muly Ilan, Hi Sorry for the delayed response. Thanks for the comments. Please find below the reply tagged [VM]. Regards, Venkat. On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan wrote: > Hi,**** > > ** ** > > I have 2 comments to draft-ietf-tp-te-mib-02:**** > > **1. **In mplsXCExtTable =96 suggest to make the mplsXCExtTunnelPoi= nter > a read-only object. The NE can automatically fill in this backward pointe= r > value when the manager sets the mplsTunnelXCPointer in the mplsTunnelTabl= e. > This will be similar to the existing backward pointers mplsInSegmentXCInd= ex > & mplsOutSegmentXCIndex. > > [VM] Yes, we will consider this change in our next version. > > **2. **In mplsTunnelExtTable =96 suggest to add a columnar object > mplsTunnelExtRemoteTunnelIndex. This will hold the index of the > bidirectional tunnel at the egress LSR. To support LSP connectivity > verification per RFC6428, detection of mis-connectivity defect, the > (global-id, node-id, tunnel-num and lsp-num) should be known at both ends= . > The global-id and node-id of the remote LSR are available from > mplsNodeConfigTable. Assuming co-routed LSPs, the lsp-num is given by > mplsXCLspId. The only missing identifier is the remote tunnel-num since > per RFC6370 each end can have its own tunnel number.**** > > **[VM] Yes, your suggestion is exactly matching with our next version > update. Please find below the expected additional MIB objects > for mplsTunnelExtTable, > > 1. mplsTunnelExtDestTnlIndex > > 2. mplsTunnelExtDestTnlInstance > 3. mplsTunnelExtDestTnlValid - TRUE/FALSE TRUE will be set if MIB objects mplsTunnelExtDestTnlIndex and mplsTunnelExtDestTnlInstance are used for destionation tunnel indentification, FALSE will be set otherwise. 4. mplsTunnelExtOppositeDirTnlValid - TRUE/FALSE TRUE will be set if MIB object mplsTunnelOppositeDirPtr is used for destination tunnel identifiction, FALSE will be set otherwise. > ** > > ** ** > > Regards,**** > > ** ** > > *Muly Ilan*** > > Senior System Architect, R&D**** > > T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930 | > muly_i@rad.com **** > > RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, > Israel | www.rad.com**** > > ** ** > > ** ** > --20cf3071d0c453181004bcbfc49a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Muly Ilan, Hi
Sorry for the delayed response.
= =A0
Thanks for the comments. Please find below the reply tagged [= VM].
=A0
Regards,
Venkat.
On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan <muly_i@rad.com> wrote:

Hi,

=A0

I have 2 comments to draft-ietf= -tp-te-mib-02:

1.=A0=A0=A0= =A0=A0=A0 I= n mplsXCExtTable =96 suggest to make the mplsXCExtTunnelPo= inter a read-only object. The NE can automatically fill in t= his backward pointer value when the manager sets the mplsTunnelXCPoint= er in the mplsTunnelTable. This will be simila= r to the existing backward pointers mplsInSegmentXCIn= dex & mplsOutSegmentXCIndex.

<= span lang=3D"EN-AU">[VM] Yes, we will consider this change in our next vers= ion.

2.=A0=A0=A0= =A0=A0=A0 I= n mplsTunnelExtTable =96 suggest to add a columnar object mplsTunnelExtRemoteTunnelIndex. This w= ill hold the index of the bidirectional tunnel at the egress LSR. To suppor= t LSP connectivity verification per RFC6428, detection of mis-connectivity defect, the (global-id, node-id, tunnel-num and lsp= -num) should be known at both ends. The global-id and node-id of the remote= LSR are available from mplsNodeConfigTable. Assuming co-routed LSPs, the lsp-num is given by mplsXCLspId. The = only missing identifier is the remote tunnel-num since per RFC6370 each end= can have its own tunnel number.<= /p>

[VM] Yes,=A0your suggest= ion is exactly matching with our next version update. Please find below the= expected additional MIB objects for=A0mplsTunnelExtTable,

1. mplsTunnelExtDestTnlIndex

2. mplsTunnelExtDestTnlInstance

=A0=A0=A0 3. mplsTunnelExtDestTnlValid - TRUE/FAL= SE
=A0=A0=A0=A0=A0=A0 TRUE will be set if MIB objects mplsTunnelExtDestTn= lIndex and mplsTunnelExtDestTnlInstance are used for destionation tunnel in= dentification, FALSE will be set otherwise.
=A0=A0=A0 4. mplsTunn= elExtOppositeDirTnlValid - TRUE/FALSE
=A0=A0=A0=A0 TRUE will be set if MIB object mplsTunnelOppositeDirPtr i= s used for destination tunnel identifiction, FALSE will be set otherwise.

=A0

=A0

Regards,

=A0

Muly Ilan

Senior System Architect, R&D=

T: +972-3-765-7035 | M: +972-54-<= span style=3D"font-family:"Verdana","sans-serif";font-s= ize:8pt">470-1004 | F: +972-3-644-0930 =A0| muly_i@rad.com

RAD Data Communication= s Ltd. 24, Raoul Wallenberg=A0St. Tel-Aviv 69719, Israel=A0=A0| www.rad.com

=A0

=A0


--20cf3071d0c453181004bcbfc49a-- From mustapha.aissaoui@alcatel-lucent.com Fri Apr 6 11:13:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7E21F85E6 for ; Fri, 6 Apr 2012 11:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EYRULjlz1fm for ; Fri, 6 Apr 2012 11:13:02 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0A88621F84D1 for ; Fri, 6 Apr 2012 11:12:57 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q36ICrn6004428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Apr 2012 13:12:53 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q36ICqYv029249 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Apr 2012 13:12:52 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.147]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Fri, 6 Apr 2012 13:12:52 -0500 From: "Aissaoui, Mustapha (Mustapha)" To: "Rajiv Asati (rajiva)" Date: Fri, 6 Apr 2012 13:12:49 -0500 Thread-Topic: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) Thread-Index: Ac0P61e0pkLC22/8TxOYmnsbuMkv3gBWT9FgAIW35sAAL93Q0A== Message-ID: <5DF53972F7E9134782DCE51624466FE50AD5A09777@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <067E6CE33034954AAC05C9EC85E2577C07C99716@XMB-RCD-111.cisco.com> <5DF53972F7E9134782DCE51624466FE50AD5A09189@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> <067E6CE33034954AAC05C9EC85E2577C07E3777A@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C07E3777A@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "mpls@ietf.org" Subject: Re: [mpls] Rationale for Dual Hello Adjacency (was: Comments on draft-ietf-mpls-ldp-ipv6-06) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 18:13:06 -0000 Hi Rajiv, FEC resolution relies on the correct routing information. LDP cannot figure= it out by itself. In the same setup below, routing provides the reachabili= ty for FEC prefixes x and y with both outgoing interface and next-hop. LDP = has to use both information and there will be no balckholing of traffic as = I explained below. In fact, FEC prefix x can be reachable over both interfaces R2-R3 and R2-R5= in the case of equal-cost multipath and LDP on R2 must be able to use both= interfaces to forward packets for this FEC. It needs to find the label to = use over each interface by checking which LDP identifiers {LSR-id, label-sp= ace-id} advertised the next-hop address and that there is a hello-adjacency= over each the outgoing interface for a gvien {LSR-id, label-space-id}. There is no need to maintain two link Hello adjacencies over the same inter= face for resolving an IPv4 or an IPv6 FEC. I hope we can agree to this by n= ow. We just published a draft to specify LDP adjacency capability negotiation. = This is the correct way to control which FECs can be resolved to a link suc= h that we can keep IPv6 and IPv4 FEC resolution compatibe with RFC 5036 in = the case of dual-stack interfaces: http://www.ietf.org/id/draft-pdutta-mpls-ldp-adj-capability-00.txt Please let me know if you have any comments. Mustapha. -----Original Message----- From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] Sent: Thursday, April 05, 2012 3:46 PM To: Aissaoui, Mustapha (Mustapha) Cc: mpls@ietf.org; Shah, Himanshu Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-iet= f-mpls-ldp-ipv6-06) Hi Mustapha, Please see inline, > Could you provide in details how you believe the presence of duplicate link- > local addresses from two neighbouring LSRs can cause blackhole of traffic? R1--R2----R3---R4----"x" \-----R5-----------"y" R2 has a path via R3 to "x". Say, routing next-hop =3D LLAx. R3 and R5 use the same LLA (=3DLLAx) towards R2. Relying on just RFC5036 section 2.7 that describes the next-hop/label resol= ution using ADDRESS message and says nothing about Hello Adjacency, R2 may map LLAx to R5 and use R5's label while forwarding to R3. This would= result in blackholing of the traffic. http://tools.ietf.org/html/rfc5036#section-2.7 2.7. LDP Identifiers and Next Hop Addresses // forwarding. To retrieve the label, the LSR must be able to map the next hop address for the prefix to an LDP Identifier. .... To enable LSRs to map between a peer LDP Identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages. // Cheers, Rajiv > -----Original Message----- > From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel- > lucent.com] > Sent: Monday, April 02, 2012 11:20 PM > To: Rajiv Asati (rajiva) > Cc: mpls@ietf.org; Shah, Himanshu > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) > > Hi Rajiv, > Could you provide in details how you believe the presence of duplicate link- > local addresses from two neighbouring LSRs can cause blackhole of traffic? > > What you describe in Section 8 is already how implementations of RFC 5036 > operate. Before you can resolve a FEC to a link, you have to find out the > outgoing interface and next-hop of that FEC prefix in the routing table. Then > you need to find the LSR-id which advertised that next-hop address as its local > address and that there is a hello adjacency to that LSR-id over that interface. In > the case of a dual-stack inteface, you just need to find a link Hello adjacency > over that interface, it does not have to be an IPv6 adjacency, to resolve an IPv6 > FEC. > > Because LDP follows routing, you cannot blackhole traffic when overalpping > link-local addresses exist to different LDP peers over two different interfaces or > subnets. If overlapping occurs over the same subnet, then neighbour discovery > will detect it and will shutdown IPv6 forwarding over that interface. > > Again, there is no relationship of FEC resolution to a link and the type of the > control plane adjacency. You just need to have an adjacency. > > Regards, > Mustapha. > > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > Sent: Sunday, April 01, 2012 6:20 AM > To: Shah, Himanshu > Cc: mpls@ietf.org; Aissaoui, Mustapha (Mustapha) > Subject: RE: Rationale for Dual Hello Adjacency (was: Comments on draft-ietf- > mpls-ldp-ipv6-06) > > Hi Himanshu, > > Appreciate your question. There are at least two benefits for sending > IPv6 hello & IPv4 hello and maintaining hello adj for both on a dual-stack > interface if enabled with both LDP IPv4 and LDP IPv6: > > 1. Discovering v4 or/and v6 transport that the peer is willing to use for > bootstrapping the subsequent TCP session (and resorting to using the alternate > transport if the preferred one failed) > Similar to that of happy eyeball (unless hardcoded or got into collision)! > > 2. Resolving the label correctly even if duplicate IPv6 LLAs are used as the > routing next-hops > Please see section 8 for more details > http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6-06#section-8 > > While it may be tempting to maintain only one hello adj (IPv4, say) (that got > used to establish the subsequent (IPv4, say) TCP/LDP session) and let go of the > other hello adj (IPv6, say) that didn't get used, it could cause traffic blackholing > (due to missing #2 above) for packets going on LSPv6. > > Does this clarify? > > Cheers, > Rajiv > > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Wednesday, March 28, 2012 4:06 PM > > To: Aissaoui, Mustapha (Mustapha); Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > I second the same concern and fail to understand the rationale to > bypass the > > available > > tool (capacity negotiation). > > Thanks, > > himanshu > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of > > Aissaoui, Mustapha (Mustapha) > > Sent: Wednesday, March 28, 2012 3:56 PM > > To: Rajiv Asati (rajiva) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Rajiv, > > I am afraid we are not making progress on the technical questions I > raised on > > this draft. > > > > For the benefit of everyone else on the mailing list, I am going to > state the > > main issue with the current proposal in draft-ietf-mpls-ldp-ipv6-06. > This > > proposal is inferring the type of FEC (unicast IPv4 or unicast IPv6) > which can be > > resolved in the datapath over a given link based on the type of the > control > > plane adjacency (IPv4 or IPv6) established over that link. This > coupling of FEC > > resolution to the type of control plane adjacency is not correct and > breaks so > > many things in RFC 5036. In RFC 5036, the ability to resolve a FEC > type between > > peers is independent of the adjacency established. > > > > In addition, this proposal now means that we need 2 link Hello > adjacencies over > > each link and 2 targeted Hello adjacencies between any two LSR nodes. > This is > > not good from a scaling perspective while it provides no gain. > > > > In an earlier exchange on this thread, we discussed the need for > introducing > > per Hello adjacency capability negotiation to address the probem of > which FEC > > types can be resolved over a given link adjacency. That is the correct > approach > > to the problem and we should keep the behaviour of RFC 5036 as is, > that is an > > IPv4 link Hello adjacency will bootstrap an IPv4 LDP session and an > IPv6 link > > adjacency will bootstrap an IPv6 LDP session. There is no need or > value for two > > link Hellos associating with the same IPv4 or IPv6 LDP session. > > > > Regards, > > Mustapha. > > > > -----Original Message----- > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > Sent: Monday, March 12, 2012 12:25 PM > > To: Aissaoui, Mustapha (Mustapha) > > Cc: mpls@ietf.org; Carlos Pignataro (cpignata) > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > Hi Mustapha, > > > > Thanks for the discussion. Please see inline, > > > > 1. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > > > 2. > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > It is not about the FEC. It is about the LSP, and rightfully so. > > > > Hopefully, answering this Q will help us - If there are 3 links (LDP > > enabled) between two LSRs and only two have hello adj leading to the > working > > LDP session, then would the LSRs use the 3rd link (which doesn't have > valid > > hello adj) for MPLS packet forwarding? > > > > - If your answer is Yes, then we have a fundamental disagreement > independent > > of LDP IPv6. > > - If the answer is No, then that's inline with what's described in the > last para of > > section 3 - differentiating IPv4 hello adj from IPv6 hello adj. > > Perhaps, the text needs a bit of rephrasing, so please feel > free to suggest. > > > > The above has no bearing on FEC type e.g. IPv4 packet being sent over > > LSPv6 or vice versa. > > > > Hence, we leave the text as-it-is. > > > > > > 3. > > > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > Removing last paragraph of section 2.5.2 from RFC 5036 ? > > > > That would fundamentally break RFC5036. > > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. > > > > Correct and that's because each LSR uses the same LDP Identifier and > qualifies > > for the point 1 of section 2.5.2 in RFC5036, which suggests to not > establish a > > new session if there is already one existing using the same LDP > Identifier: > > > > // > > 1. If LSR1 does not already have an LDP session for the exchange > > of label spaces LSR1:a and LSR2:b, it attempts to open a TCP > // > > > > > > > It becomes an issue of association of multiple Hello adjacencies > with > > > a single TCP connection. > > > > And it is not an issue thanks to the last para of section 2.5.2. We > can NOT afford > > to remove it. > > > > Hence, we leave the text as-it-is in section 4 of ldp-ipv6. > > > > > > 4. > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > That's incorrect. As you know, PW-FEC, as per RFC5036, already > requires > > 'extended/targetted hello adj', not 'basic hello adj' with the peer > before > > exchanging PW-FECs with that peer. > > > > In an IPv6-only environment, IPv6 link hellos must be sent when LDPv6 > is > > enabled on an interface. This is already implicit in RFC5036. > > And if the interface is a dual-stack interface, then the behavior > shouldn't > > change. > > > > > > 5. > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. > > > > Well, RFC5036 (LDP version 1) prescribes using a single session for > exchanging > > FEC-label bindings for various FEC types. > > > > We could work on version 2 to move away from that intention e.g. allow > using > > more than one session between two LSRs. > > > > > BGP allows the exchage of IPv4 prefixes over an IPv6 connection and > > > vice-versa. There is no relationship whatsoever between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > Well said, and that's indeed what RFC5036/ldp-ipv6 are specifying. > > Whether the session is LDPoIPv4 or LDPoIPv6, let all the FEC types be > > exchanged, as permitted. > > We are in agreement here. > > > > 6. > > Given the lack of response for #6, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 7. > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > > Please see my response to #4. Nonetheless, this is moot, as it is a > MAY, and is > > local to the LSR. > > FWIW, this point has been beaten to death last yr, and I would urge > you to > > check the discussion on the mailing list from last yr. > > > > 8. > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > If the node still receives the unsupported FEC or address type, then > it indicates > > that the peer has a bug, and it should follow the behavior specified > in RFC5036 > > e.g. declare a fatal error. > > > > This is orthogonal to capability or FEC filter, since the assumption > here is that > > an LSR is willing to send/receive FEC-label bindings for both IPv4 and > IPv6 and > > more. The point is that the loophole that has existed all along is > closed when an > > LSR gets upgraded with the code compliant with this specification. > > > > 9. > > Given the lack of response for #1, I am assuming this we have agreed > and > > closed the discussion on this point. Thanks. > > > > 10. > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > You do make a good point about us not changing the LDP protocol > version, so, it > > is not a new protocol, and I agree. > > I will consider to change GTSM to optional (MAY), subjected to > Carlos's opinion. > > > > We will revisit it if/when the consensus suggests otherwise prior to > RFC > > publication. > > We can close this point as well. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: Aissaoui, Mustapha (Mustapha) > [mailto:mustapha.aissaoui@alcatel- > > > lucent.com] > > > Sent: Friday, March 02, 2012 1:09 AM > > > To: Rajiv Asati (rajiva) > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Rajiv, > > > See some follow-up inline. > > > > > > Regards, > > > Mustapha. > > > > > > -----Original Message----- > > > From: Rajiv Asati (rajiva) [mailto:rajiva@cisco.com] > > > Sent: Wednesday, February 29, 2012 10:28 PM > > > To: Aissaoui, Mustapha (Mustapha); Shane Amante > > > Cc: mpls@ietf.org > > > Subject: RE: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > Hi Mustapha, > > > > > > Thanks for the review of the document and the feedback. It is never > > too late. > > > :) Sorry about the delay in getting back to you. > > > > > > Please see inline, > > > > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > Yes, they were discussed in the past and closed. > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > No. > > > > > > While it is a common practice to assign a host route to the loopback > > interface, > > > and it is a common practice to use loopback interface as the > next-hop, > > we > > > must not assume the common practice to be the norm for the protocol. > > In > > > fact, there is NO technical argument against using the non-host > route > > on a > > > loopback interface. > > > > > > In fact, almost every implementation allows the next-hop to be a > > non-host > > > route, and I am aware of at least one implementation that allows LDP > > to > > > correctly resolve the next-hop when it uses a non-host route. > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > RFC5036 actually does make a tie in section 2.5.5 in the sense that > if > > hello adj > > > ceases to exist on an interface, then LDP concludes the lack of MPLS > > > forwarding on that interface. So, if IPv6 hello adj failed, then > stop > > the IPv6 > > > MPLS forwarding (i.e. LSPv6) on that int, and vice versa, instead of > > blindly > > > stopping MPLS forwarding altogether. That wouldn't make sense. > > > > > > // > > > when it receives a Hello that matches the adjacency. If the > timer > > > expires without receipt of a matching Hello from the peer, LDP > > > concludes that the peer no longer wishes to label switch using > that > > > label space for that link (or target, in the case of Targeted > > Hellos) > > > or that the peer has failed. The LSR then deletes the Hello // > > > > > > MA> Not really. The "matching" has nothing to do with the type of > FEC. > > It has > > > to do with the parameters of the adjacency (LSRid, label space) over > > that link. > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > > > I agree. It doesn't have anything to do with the address family, but > > it > > > becomes restrictive when having to accommodate transport of two > > different > > > address families (IPv4 and IPv6). Pls see more details on this later > > on. > > > > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > That's not correct (and the implementation is in violation of > > RFC5036). > > > > > > We had good discussion on this early on. In fact, we had an editor's > > note on > > > this in initial versions of this document to solicit discussion on > > that. > > > > > > The last para of section 2.5.2, as stated, would result in a > > particular IP address > > > (1.1.1.1, say) being encoded in the transport address in both > > > IPv4 LDP Hello and IPv6 LDP hello. And if the label space is shared > > (which is > > > what the WG agreed to during IETF 80), then it prohibits IPv6 hello > > from > > > carrying IPv6 transport address (or IPv4 hello from carrying > > > IPv4 transport address). It would not make sense. > > > > > > In other words, we wouldn't want IPv4 Hello to carry IPv6 transport > > address > > > and vice versa. It wouldn't make sense and would be incorrect. > > > > > > That's why the change was needed. > > > > > > MA> When parallel links exist between two LSRs, the TCP connection > is > > > bootstrapped by one of the hello adjacencies. An implementation > > compliant > > > to RFC 5036 will not accept two TCP connections between the same two > > LSRs > > > and thus the fact that the transport addresses exchanged are > different > > has > > > no impact. In fact take the simple case of a link LDP and a T-LDP > > sessions for > > > directly connected LSRs. The T-LDP can use a loopback address as the > > > transport address while the link LDP can use the link address as the > > transport > > > address and they will both share the same TCP connection which was > > > bootstrapped first. It becomes an issue of association of multiple > > Hello > > > adjacencies with a single TCP connection. That is why I am saying > the > > last > > > paragraph of section 2.5.2 should be removed from RFC 5036. > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > We thought so too, but we uncovered various corner cases in which > this > > > becomes problematic, not to mention that the indeterminism it would > > bring > > > into the picture. The easiest was to maintain hello adj per > > address-family per > > > peer. > > > > > > For ex, consider three LDP enabled interfaces between R1 and R2, > where > > > two are dual-stack, whereas the 3rd is single-stack (v4). If they > > maintain only > > > single adj, then they would have hello adj of one transport (v6, > say) > > on dual- > > > stack interfaces, and another transport (v4, > > > say) on 3rd interface. > > > > > > Hello adj is tightly coupled with the functional LDP peering. If > (the > > > last) hello adj is lost, then LDP peering must be brought down. > > > Additionally, if hello adj is gone from an interface, then LDP > should > > prohibit > > > MPLS forwarding from using that interface. > > > > > > Another way to think about it is - if IPv4 stops functioning on an > > interface, but > > > IPv6 keeps functioning, then IPv6 MPLS forwarding should not be > > penalized. > > > And vice versa. > > > > > > Having separate hello adj maintenance is much cleaner/simpler and > > provides > > > deterministic behavior. > > > > > > Nonetheless, an implementation could choose to optimize, if needed, > to > > > keep both address-family related info in a single adjacency > structure, > > but this > > > is all implementation specific. :) > > > > > > MA> The proper way to handle this is to implement separate LDP > > sessions > > > not separate Hello adjacencies sharing the same LDP session. Current > > > standard LDP based on RFC 5036 allows PW-FEC and mLDP FECs to be > > > exchanges and they do not require separate hello adjacencies. These > > are just > > > FEC types and have no relationship whatsoever to the type of > > adjacency. > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > Good point, but this is a different problem. It is not about the > > sequence > > > (which was ok if IPv4 hellow as carrying two IPv4 transport > > addresses). > > > > > > The problem is that allowing IPv4 based "discovery" to suggest an > IPv6 > > > transport address is fundamentally a wrong approach, IMO. How would > > IPv4 > > > know that IPv6 transport is even functional (and vice versa). IPv4 > > based > > > discovery should suggest IPv4 transport, and IPv6 based discovery > > should > > > suggest IPv6 transport. > > > > > > MA> Again, what you are asking for can be solved with the use of > > separate > > > LDP sessions for IPv4 and IPv6. This is a deployment choice and not > a > > protocol > > > design decision. BGP allows the exchage of IPv4 prefixes over an > IPv6 > > > connection and vice-versa. There is no relationship whatsoever > between > > the > > > type of TCP conneciton in BGP and the NRLI family exchanged. > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > We need the address-family awareness in peer hello adjacency/s, > > whether it > > > is a kept in a single adj structure or not. > > > > > > Loosing the AFI awareness leads up the other problems that I > mentioned > > > earlier. > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > It is MAY. :) > > > It was changed to MAY based on the exhaustive discussion on mailing > > list in > > > 2011 for us to move forward. > > > > > > MA> Bottom line, you are changing the behaviour of RFC 5036. This is > a > > > different protocol. > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > We initially thought so too, until we discovered the following very > > explicitly in > > > RFC5036. This is a recipe for a disaster, if left untreated. > > > > > > // > > > Section 3.5.5.1 - > > > If an LSR does not support the Address Family specified in the > Address > > List > > > TLV, it SHOULD send an Unsupported Address Family Notification to > its > > LDP > > > signaling an error and abort processing the message. > > > > > > Section 3.4.1.1 - > > > If in decoding a FEC TLV an LSR encounters a FEC Element with an > > Address > > > Family it does not support, it SHOULD stop decoding the FEC TLV, > abort > > > processing the message containing the TLV, and send an "Unsupported > > > Address Family" Notification message to its LDP peer signaling an > > error. > > > // > > > > > > MA> Well all this is controlled via the LDP capability or > configuring > > the FEC > > > filters. If after this, the node still receives the unsupported FEC > or > > address > > > type, what else do you suggest it should do? > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > Because it is native in IPv6 to allow for link-local addresses that > > IPv4 never > > > allowed. > > > So, what was an anomaly with IPv4 is now a standard behavior with > > IPv6, > > > hence, that verbiage. > > > > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > We posed the Q about GTSM being the default or not during IETF 80, > and > > > there were 10-yes and 0-no (mostly from operators) Pls see the > > minutes, > > > http://www.ietf.org/proceedings/80/minutes/mpls.txt > > > > > > MA> Well that certainly contradicts the process. If you are creating > a > > new LDP > > > version protocol, we can consider making it mandatory by default. If > > you > > > claim you are still compliant to RFC 5036 then you cannot change it > > and it > > > must remain optional. > > > > > > Cheers, > > > Rajiv > > > > > > > > > > -----Original Message----- > > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of > > > > Aissaoui, Mustapha (Mustapha) > > > > Sent: Monday, February 06, 2012 3:21 PM > > > > To: Shane Amante > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Hi Shane, > > > > LDP as defined in RFC 5036 can carry multiple FEC types within an > > LDP > > > session > > > > from a peer which is identified by the LDP identifier tuple > {LSR-id, > > > label-space- > > > > id}. If two LSR nodes using the same LSR-id want to advertise two > > > different label > > > > spaces, then they must use two different Hello adjacencies and LDP > > > sessions for > > > > that. Also, if an implementation supports virtualization of LDP, > > then > > > a different > > > > LDP identifier altogether can be used to establish a separate LDP > > > session. Other > > > > than that, there is no relation between the type of adjacency and > > the > > > FEC which > > > > are carried. For example, the same LDP Hello Adjacency and LDP > > session > > > are > > > > used to carry unicast FECs, multicast FECs (mLDP), and PW FECs > > between > > > two > > > > directly connected peers. > > > > > > > > As far as I know BGP is not very different. It offers the ability > to > > > carry IPv4 NLRI > > > > over a IPv6 session and vice versa. > > > > > > > > If what is required is to carry IPv6 FECs on an IPv6 session and > > IPv4 > > > on an IPv4 > > > > session between two LSRs, then we should consider extending RFC > > 5036 > > > to > > > > allow for two different LSR-id values sharing the same global > label > > > space. This > > > > way, we can have separate Hello adjacency and LDP session and it > is > > up > > > to the > > > > user to assign which FEC type is allowed on which LDP session. > This > > is > > > a new > > > > work item but in my view much cleaner and backward compatible with > > RFC > > > > 5036 than to try to tie the address family to the type of Hello > > > adjacency. > > > > > > > > By the way, draft-ietf-mpls-ldp-ipv6-06 is allowing for a separate > > > Hello > > > > adjacency but a single shared LDP session. It is not exactly what > > you > > > are asking > > > > for. > > > > > > > > Regards, > > > > Mustapha. > > > > > > > > -----Original Message----- > > > > From: Shane Amante [mailto:shane@castlepoint.net] > > > > Sent: Friday, February 03, 2012 11:32 PM > > > > To: Aissaoui, Mustapha (Mustapha) > > > > Cc: mpls@ietf.org > > > > Subject: Re: [mpls] Comments on draft-ietf-mpls-ldp-ipv6-06 > > > > > > > > Mustapha, > > > > > > > > I am not an author, but I do want to provide some operational > input > > on > > > some of > > > > your comments. Specifically, I get the sense from several of your > > > comments -- > > > > actually, moreso from #3 -- that you are opposed to maintaining > > > separate LDP > > > > Hello and/or Session Adjacencies: 1 for each address family. (If > my > > > impression > > > > is incorrect I apologize). > > > > > > > > I actually *do* want to have separate LDP Hello and Session > > > adjacencies: one > > > > per address family, at least at this point in time. I'm concerned > > > about > > > > [operational] issues that may develop in, for example, v6 > affecting > > > the > > > > exchange of Hellos and/or FEC's + Labels for v4 or vice-versa. As > > one > > > more > > > > concrete example, 6man/v6ops are only right now working on > improving > > > the > > > > robustness of IPv6 ND to DoS attacks. There are potentially other > > > areas where > > > > IPv6 will be hardened, as well. The bottom-line is I do not want > > > problems in v6 > > > > to affect exchange of FEC's + labels for v4, or vice-versa. Also, > > > FWIW, there has > > > > already been a precedent here wrt BGP where there it maintains > > > separate > > > > neighbors/sessions for each address family, so why aren't we doing > > the > > > same > > > > thing for LDP? > > > > > > > > Ultimately, having separate sessions over-the-wire is much more > > > intuitive to > > > > operators in lots of cases where they may expect that a > > configuration > > > change > > > > or bugs they /think/ are only going to affect one address family, > > > really do only > > > > affect one address family. Besides, LDP Hello & Sessions timers, > > when > > > set to > > > > default, are extremely relaxed (order of several seconds), so the > > > burden on > > > > implementations to maintain separate sessions should be miniscule. > > > > > > > > IMO, I would prefer that the default be separate Hellos & Sessions > > > over the > > > > wire to avoid "fate sharing". Only when an operator chooses to > > > explicitly > > > > configure their device to have hellos and sessions share fate > should > > > the device > > > > do so. > > > > > > > > Just my $0.02, > > > > > > > > -shane > > > > > > > > > > > > > > > > On Feb 3, 2012, at 4:12 PM, Aissaoui, Mustapha (Mustapha) wrote: > > > > > Dear authors, > > > > > below are comments on this draft. I realize this draft passed WG > > > last call but I > > > > think the issues are significant enough in my view. I apologize if > > > some of these > > > > comments were already raised on this mailing list. > > > > > > > > > > Regards, > > > > > Mustapha. > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > > > 1. Section 3 - LSP Mapping; second paragraph. > > > > > MA> I believe the 3rd rule in Section 2.1 of RFC 5036 is > referring > > > to a > > > > loopback interface of the egress router, not any other interface. > > That > > > is why > > > > RFC 5036 explicitly states /32 for IPv4. In my view, we should > > > explicitly refer to > > > > /128 for IPv6. > > > > > > > > > > > > > > > 2. Section 3 - LSP Mapping; last Paragraph: > > > > > " > > > > > Additionally, it is desirable that a packet is forwarded to an > LSP > > > of an egress > > > > router, only if LSP's address-family (e.g. LSPv4 or LSPv6) matches > > > with that of > > > > the LDP hello adjacency on the next-hop interface. > > > > > " > > > > > MA> RFC 5036 makes no tie, and there should not be, between the > > type > > > of > > > > resolved FEC and the adjacency to the next-hop. I think this > > statement > > > should be > > > > removed. > > > > > > > > > > > > > > > 3. Section 4 - LDP identifiers; third paragraph: > > > > > " > > > > > This document qualifies the first sentence of last paragraph of > > > > > Section 2.5.2 of [RFC5036] to be per address family and > > therefore > > > > > updates that sentence to the following: "For a given address > > > family > > > > > over which a Hello is sent, and a given label space, an LSR > MUST > > > > > advertise the same transport address." This rightly enables > the > > > per- > > > > > platform label space to be shared between IPv4 and IPv6. > > > > > " > > > > > MA> I do not think the last paragraph Section 2.5.2 in RFC 5036 > > has > > > anything > > > > to do with the address family. It only requires that an LSR > > advertises > > > the same > > > > transport address in all Hello adjacencies that advertise the same > > > label space. > > > > In fact the intent as explained in the second sentence of that > same > > > paragraph > > > > was to make sure that if two LSRs are establishing multiple Hello > > > adjacencies > > > > that they play the same active/passive role for establishing the > TCP > > > connection. > > > > > > > > > > In practice though, most implementations allow Hello adjacencies > > > over > > > > parallel links with different IPv4 transport addresses and it > works > > > just fine. I > > > > think we should remove this restriction from RFC 5036 and not > refer > > to > > > it in this > > > > draft. > > > > > > > > > > > > > > > 4. Section 5.1 - Basic Discovery mechanism > > > > > MA> I understand the need to send both IPv4 and IPv6 Hello > > messages > > > over a > > > > dual-stack interface since there could be both IPv4 and IPv6 LSRs > on > > > the same > > > > subnet. However, this does not justify the need to maintain two > > > separate Hello > > > > ajacencies per peer. In practice, each router can send both IPv4 > and > > > IPv6 hellos > > > > but only a single Hello adjacency must be allowed with each peer > > > (LSR-id, label- > > > > space} over a given interface, whichever came up first. Over a P2P > > > interface, it > > > > is up to the user to configure which adjacency they want to form > > which > > > means > > > > there is only a need to send one type of hello. > > > > > > > > > > > > > > > 5. Section 6.1 - Transport connection establishment " > > > > > 2. An LSR SHOULD accept the Hello message that contains both > IPv4 > > > > > and IPv6 transport address optional objects, but MUST use > > > only > > > > > the transport address whose address family is the same as > > > that > > > > > of the IP packet carrying Hello. > > > > > " > > > > > MA> This is not a new issue. If I am not mistaken, this can also > > > occur in RFC > > > > 5036 implementations if an LSR receives two optional IPv4 > transport > > > address > > > > TLVs. RFC 506 does not say what to do with this and was left for > > > > implementations to handle. If we absolutely need to specify > > something, > > > maybe > > > > we should say only the first TLV in the Hello message is > processed. > > > > > > > > > > > > > > > 6. Section 6.1 - Transport connection establishment " > > > > > 7. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if it has both IPv4 and > IPv6 > > > > > hello adjacencies for the same LDP Identifier (over a > dual- > > > > > stack interface, or two or more single-stack IPv4 and > IPv6 > > > > > interfaces). This applies to the section 2.5.2 of > RFC5036. > > > > > > > > > > 8. An LSR SHOULD prefer the LDP/TCP connection over IPv6 for a > new > > > > > LDP session with a remote LSR, if they attempted two TCP > > > > > connections using IPv4 and IPv6 transport addresses > > > > > simultaneously. > > > > > " > > > > > MA> No need for all this if you enforce that only a single > > adjacency > > > is > > > > maintained to each peer over a dual-stack interface. > > > > > > > > > > > > > > > 7. Section 7 - Label Distribution; First paragraph: > > > > > " > > > > > An LSR MAY NOT advertise both IPv4 and IPv6 FEC-label bindings > (as > > > > > well as interface addresses via ADDRESS message) from/to the > > peer > > > > > over an LDP session (using whatever transport), unless it has > > > valid > > > > > IPv4 and IPv6 Hello Adjacencies for that peer, as specified in > > > > > section 6.2. > > > > > " > > > > > MA> I do not agree that the advertisement of IPv6 label-FEC > > bindings > > > should > > > > depend on the existence of an IPv6 Hello adjacency. This is a very > > > narrow > > > > interpretation of RFC 5036. > > > > > The proper solution to this is to add an IPV6 LDP capability to > > > negotiate which > > > > FEC address family can be exchanged regardless if the Hello > > adjacency > > > is IPv4 > > > > or IPv6. This is already done for multicast LDP (mLDP) FECs. > > > > > > > > > > > > > > > 8. Section 7 - Label Distribution; Fourth paragraph: > > > > > " > > > > > Additionally, to ensure backward compatibility (and > > interoperability > > > > > with IPv4-only LDP implementations), this document specifies > that > > > > > - 1. An LSR MUST NOT send a label mapping message with a FEC TLV > > > > containing FEC Elements of different address-family. In other > words, > > a > > > FEC TLV > > > > in the label mapping message MUST contain the FEC Elements > belonging > > > to the > > > > same address-family. > > > > > 2. An LSR MUST NOT send an Address message (or Address Withdraw > > > > message) with an Address List TLV containing IP addresses of > > different > > > address- > > > > family. In other words, an Address List TLV in the Address (or > > Address > > > > Withdraw) message MUST contain the addresses belonging to the same > > > > address-family.. > > > > > " > > > > > MA> This is yet another narrow interpretation of RFC 5036. There > > is > > > no > > > > justification for such a restriction and certainly RFC 5036 does > not > > > make it. A > > > > FEC TLV contains list of FEC Elements which are opaque. Each FEC > > > Element has > > > > its own Type, Length, Value and is self sufficient. Although > > > implementations > > > > don't mix and match FEC elements but they are designed to handle > it. > > > Same > > > > applies to Address list TLV. > > > > > > > > > > > > > > > 9. Section 8 - LDP Identifiers and Next Hop Addresses > > > > > MA> I believe the need to handle duplicate interface addresses > > > received from > > > > two different peers is not a new issue. It needed to be handled in > > > existing IPv4 > > > > based LDP implementations. Maybe the authors can specify why > > duplicate > > > link > > > > local addresses is any different. > > > > > > > > > > > > > > > 10. Section 9 - LDP TTL Security " > > > > > This document also specifies that the LDP/TCP transport > connection > > > > > over IPv6 (i.e. LDPoIPv6) must follow the Generalized TTL > > Security > > > > > Mechanism (GTSM) procedures (Section 3 of [RFC5082]) for an > LDP > > > > > session peering established between the adjacent LSRs using > > Basic > > > > > Discovery, by default. > > > > > " > > > > > MA> GTSM must be optional as explained in RFC 5082. This draft > is > > > not > > > > defining a new protocol and as such it should remain optional as > in > > > RFC 5036. > > > > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > =3D=3D=3D=3D=3D=3D > > > > =3D=3D=3D=3D=3D=3D > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > mpls mailing list > > > > mpls@ietf.org > > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Fri Apr 6 12:18:22 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC4011E8098 for ; Fri, 6 Apr 2012 12:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPekf9YnWP8O for ; Fri, 6 Apr 2012 12:18:21 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6805B11E8093 for ; Fri, 6 Apr 2012 12:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=2070; q=dns/txt; s=iport; t=1333739901; x=1334949501; h=from:subject:date:message-id:cc:to:mime-version; bh=kxYxTQ23TbDd1ApB1nxVTcnLEUtCQpz6SIlqcNykNfo=; b=WGZQJ0rlhquhN95yxzXnAyDZr4M3c201shelU/tR9mxWfXUJ6IxsEC9N XoRxipsYpLTTF4CbMO6keavy4cyu25f92EQJ60Yh4MGY4luYoyKgXc06V X5XTKopat1EuZlmynqmyqVfg3kbKpxHH8NpgvEXTnnCENjFi4jfoMZsXH 0=; X-Files: signature.asc : 203 X-IronPort-AV: E=Sophos;i="4.75,381,1330905600"; d="asc'?scan'208,217";a="72730734" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 06 Apr 2012 19:18:21 +0000 Received: from dhcp-64-102-209-109.cisco.com (dhcp-64-102-209-109.cisco.com [64.102.209.109]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q36JIKCY031129; Fri, 6 Apr 2012 19:18:20 GMT From: Carlos Pignataro Content-Type: multipart/signed; boundary="Apple-Mail=_01FE81B9-D3A6-4CBF-8BA8-AC4CB379145A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 6 Apr 2012 15:18:20 -0400 Message-Id: To: George Swallow , Loa Andersson , Ross Callon Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: mpls@ietf.org Subject: [mpls] Fwd: draft-chen-mpls-ipv6-pw-lsp-ping-03 - Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 19:18:22 -0000 --Apple-Mail=_01FE81B9-D3A6-4CBF-8BA8-AC4CB379145A Content-Type: multipart/alternative; boundary="Apple-Mail=_79B2B639-2AD4-402E-BCDB-9BACBE1D32A7" --Apple-Mail=_79B2B639-2AD4-402E-BCDB-9BACBE1D32A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii George, chairs, This document is quite straightforward and has been stable for some = time. We have incorporated all the comments that we received from the = WG. http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-03 We would like to request if you could poll the group for WG adoption as = an MPLS WG doc. Thank you, -- Carlos & Mach.= --Apple-Mail=_79B2B639-2AD4-402E-BCDB-9BACBE1D32A7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
George, chairs,

This document is quite straightforward and has been stable for some time. We have incorporated all the comments that we received from the WG.

http://tools.ietf.org/html/draft-chen-mpls-ipv6-pw-lsp-ping-03

We would like to request if you could poll the group for WG adoption as an MPLS WG doc.

Thank you,

-- Carlos & Mach.
--Apple-Mail=_79B2B639-2AD4-402E-BCDB-9BACBE1D32A7-- --Apple-Mail=_01FE81B9-D3A6-4CBF-8BA8-AC4CB379145A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9/QXwACgkQtfDPGTp3USy13ACg0UGLSxUlJsXioLfDbBeCl1Dj 36gAn3iI6OJpBCWQqmk2kgEpBATzj5C4 =ChnW -----END PGP SIGNATURE----- --Apple-Mail=_01FE81B9-D3A6-4CBF-8BA8-AC4CB379145A-- From huaimo.chen@huawei.com Sun Apr 8 17:56:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101CE21F84AE for ; Sun, 8 Apr 2012 17:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qfZQcuErg2E for ; Sun, 8 Apr 2012 17:56:42 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADEE21F846D for ; Sun, 8 Apr 2012 17:56:42 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB20345; Sun, 08 Apr 2012 20:56:41 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Apr 2012 17:56:14 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Sun, 8 Apr 2012 17:56:11 -0700 From: Huaimo Chen To: Yimin Shen , "draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org" Thread-Topic: comments on draft-chen-mpls-p2mp-ingress-protection Thread-Index: Ac0JGTG4v7yHr4wFQ/e3Na8ErxEObwAEkhnAAL1yggACchliIA== Date: Mon, 9 Apr 2012 00:56:10 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F6269@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.103] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F6269dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-chen-mpls-p2mp-ingress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 00:56:46 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F6269dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yimin, See my answers inline below. Best Regards, Huaimo ________________________________ From: Yimin Shen [mailto:yshen@juniper.net] Sent: Tuesday, March 27, 2012 9:27 AM To: Huaimo Chen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: RE: comments on draft-chen-mpls-p2mp-ingress-protection Huaimo, The following items from your clarification for my comment [1] and [3] may = impact the applicability of the draft. - The primary ingress node should be directly connected to the back= up ingress node. That is that the primary ingress node and the backup ingre= ss node should be one hop away. - If the backup ingress node can not do CSPF, it should have a way = to get a path. For example, PCE may be used to compute the path. In a norma= l situation, how does a router without CSPF capability get a protection pat= h satisfying a given set of constraints? [[Chen,Huaimo]] It seems that a router supporting MPLS TE should have CSPF = capability. A router supporting MPLS TE should be able to compute a path sa= tisfying a given set of constraints for an MPLS TE LSP originated from it. = If a router supporting MPLS TE does not have any CSPF capability itself, it= should have a way already to get a path satisfying a given set of constrai= nts for an MPLS TE LSP originated from it. Two more comments: [7] TE constraints for CSPF on backup ingress PE Are the TE constraints used by a backup ingress PE for CSPF same or differe= nt than those used by the primary ingress PE? Either case, how does a backup ingress PE know about the TE constraints ? T= he "LSP info" message is basically a copy of Path message of the primary P2= MP LSP, and it contains only bandwidth info. What about other TE constraint= s that the backup PE must consider ? [8] Reversion Please describe all possible revertive modes. I have the following concern,= as the reversion would be driven by the two PEs, rather than a single CE. When the primary ingress PE is restored, it will make an independent decisi= on to start forwarding traffic again over the primary P2MP LSP. Likewise, t= he backup ingress PE will detect the active state of the primary PE and mak= e an independent decision to stop forwarding traffic. It seems unavoidable = that there would be a window where both PEs are forwarding traffic at the s= ame time. This would generate duplicate traffic in the network. How do you = handle such kind of scenario ? Thanks, -Yimin Shen Juniper Networks From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Friday, March 23, 2012 4:05 PM To: Yimin Shen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: RE: comments on draft-chen-mpls-p2mp-ingress-protection See my answers inline below. Regards, Huaimo ________________________________ From: Yimin Shen [mailto:yshen@juniper.net] Sent: Friday, March 23, 2012 1:20 PM To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: comments on draft-chen-mpls-p2mp-ingress-protection Authors, I have following comments for this draft. The draft allows a primary ingress router to send an "LSP info" message to = a backup ingress to set up a backup p2mp LSP. This message defines the leaf= nodes and the set of must-traverse intermediate nodes (i.e. the set of 1st= hops of the primary p2mp LSP) for the backup p2mp LSP. [1] Security The creation of backup p2mp LSP is purely based on an external message. Sec= urity must be addressed. [[Chen,Huaimo]] The primary ingress node and the backup ingress node are in= the same trusted network. Normally the backup ingress node is directly con= nected to the primary ingress node. The LSP info message that the backup in= gress node receives is from the primary ingress node, which is in the same = trusted network as the backup ingress node. It seems that there is not any = security issue in this case. It is unclear in the draft whether a primary ingress and a backup ingress m= ust be one hop away from each other, or may be multi hops away. [[Chen,Huaimo]] The primary ingress node should be directly connected to th= e backup ingress node. That is that the primary ingress node and the backup= ingress node should be one hop away. [2] P2P LSPs If the mechanism can apply to p2p LSPs, as claimed, it needs to be addresse= d in detail. [[Chen,Huaimo]] Some details may be added in the next version. [3] CSPF It assumes that the backup ingress can do path computation, e.g. CSPF. What= if it cannot? This would affect applicability. [[Chen,Huaimo]] If the backup ingress node can not do CSPF, it should have = a way to get a path. For example, PCE may be used to compute the path. In a= normal situation, how does a router without CSPF capability get a protecti= on path satisfying a given set of constraints? [4] Debuggability Once a the primary ingress has sent a "LSP info" message to a backup ingres= s, there is no way for the primary ingress to learn the existence or succes= s/failure/error state of the backup P2MP LSP. There needs to be some mechanism, such as notification to primary ingress, = to facilitate trouble shooting. [[Chen,Huaimo]]This will be considered. [5] No explicit teardown message Please consider an explicit teardown message that a primary ingress can sen= d to tear down the backup LSP. Time-out based mechanism may be too slow. [[Chen,Huaimo]] It seems that time is critical here. [6] Merge point behavior Detail about merge point behavior: How to distinguish primary LSP and backup LSP; How to handle and propagate ResvTear and PathErr received from downstream; [[Chen,Huaimo]] Some details may be added in the next version. Thanks, -Yimin Shen Juniper Networks Thanks, -Yimin --_000_5316A0AB3C851246A7CA5758973207D4325F6269dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yi= min,

=  

 = ;   See my answers inline below.

=  

Best = Regards,

Huaim= o

From: Yimin Shen [mailto:yshen@juniper.net]
Sent: Tuesday, March 27, 201= 2 9:27 AM
To: Huaimo Chen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org
Cc: mpls@ietf.org
Subject: RE: comments on dra= ft-chen-mpls-p2mp-ingress-protection

 

Huaimo,

=  

= The following items from your clarification for my comment [1] and [= 3] may impact the applicability of the draft.

=  

-         The primary ingress node sho= uld be directly connected to the backup ingress node. That is that the primary ingress node and the = backup ingress node should be one hop away.

-         If the backup ingress node c= an not do CSPF, it should have a way to get a path. For example, PCE may be used to compute the path= . In a normal situation, how does a router without CSPF capability get a pr= otection path satisfying a given set of constraints?

[[Ch= en,Huaimo]] It seems that a router supporting MPLS TE should have CSPF capability. A router supporting MPLS T= E should be able to compute a path satisfying a given set of constraints fo= r an MPLS TE LSP originated from it. If a router supporting MPLS TE does no= t have any CSPF capability itself, it should have a way already to get a path satisfying a given set of const= raints for an MPLS TE LSP originated from it.<= /b>

=  

= Two more comments:

=  

= [7] TE constraints for CSPF on backup ingress PE

=  

= Are the TE constraints used by a backup ingress PE for CSPF same or = different than those used by the primary ingress PE?  

=  

= Either case, how does a backup ingress PE know about the TE constrai= nts ? The “LSP info” message is basically a copy of Path message of the primary P2MP LSP, and it contains only bandwid= th info. What about other TE constraints that the backup PE must consider ?=

=  

= [8] Reversion

=  

= Please describe all possible revertive modes. I have the following c= oncern, as the reversion would be driven by the two PEs, rather than a single CE.

=  

= When the primary ingress PE is restored, it will make an independent= decision to start forwarding traffic again over the primary P2MP LSP. Likewise, the backup ingress PE will detect the= active state of the primary PE and make an independent decision to stop fo= rwarding traffic. It seems unavoidable that there would be a window where b= oth PEs are forwarding traffic at the same time. This would generate duplicate traffic in the network. How d= o you handle such kind of scenario ?

=  

= Thanks,

=  

= -Yimin Shen

=  

= Juniper Networks

=  

=  

=  

=  

From: Huaimo Chen [mailto:huaimo.chen@huawei.com]
Sent: Friday, March 23, 2012= 4:05 PM
To: Yimin Shen; draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org
Cc: mpls@ietf.org
Subject: RE: comments on dra= ft-chen-mpls-p2mp-ingress-protection

 

See my answ= ers inline below.

 =

Regards,

Huaimo=

From: Yimin Shen [mailto:yshen@juniper.net]
Sent: Friday, March 23, 2012= 1:20 PM
To: draft-chen-mpls-p2mp-ingress-protection@tools.ietf.org=
Cc: mpls@ietf.org
Subject: comments on draft-c= hen-mpls-p2mp-ingress-protection

 

Authors,

 

I have following commen= ts for this draft.

 

The draft allows a prim= ary ingress router to send an "LSP info" message to a backup ingr= ess to set up a backup p2mp LSP. This message defines the leaf nodes and the set of must-traverse intermediate nodes (i.e. the s= et of 1st hops of the primary p2mp LSP) for the backup p2mp LSP.

 

[1] Security=

 

The creation of backup = p2mp LSP is purely based on an external message. Security must be addressed= .

 

[[Chen,Huaimo]] The primary ingress node and the ba= ckup ingress node are in the same trusted network. Normally the backup ingress node is directly = connected to the primary ingress node. The LSP info message that the backup= ingress node receives is from the primary ingress node, which is in the sa= me trusted network as the backup ingress node. It seems that there is not any security issue in this case. =

 

It is unclear in the dr= aft whether a primary ingress and a backup ingress must be one hop away fro= m each other, or may be multi hops away.

 

[[Chen,Huaimo]] The primary ingress node should be = directly connected to the backup ingress node. That is that the primary ingress node and the bac= kup ingress node should be one hop away.

 

[2] P2P LSPs=

 

If the mechanism can ap= ply to p2p LSPs, as claimed, it needs to be addressed in detail.=

 

[[Chen,Huaimo]] Some details may be added in the ne= xt version.

 

[3] CSPF

 

It assumes that the bac= kup ingress can do path computation, e.g. CSPF. What if it cannot? This wou= ld affect applicability.

 

[[Chen,Huaimo]] If the backup ingress node can not = do CSPF, it should have a way to get a path. For example, PCE may be used to compute the path. In = a normal situation, how does a router without CSPF capability get a protect= ion path satisfying a given set of constraints?

 

[4] Debuggability<= /o:p>

 

Once a the primary ingr= ess has sent a "LSP info" message to a backup ingress, there is n= o way for the primary ingress to learn the existence or success/failure/error state of the backup P2MP LSP. <= /font>

 

 

There needs to be some = mechanism, such as notification to primary ingress, to facilitate trouble s= hooting.

 

[[Chen,Huaimo]]This will be considered.

 

[5] No explicit teardow= n message

 

Please consider an expl= icit teardown message that a primary ingress can send to tear down the back= up LSP. Time-out based mechanism may be too slow.

 

[[Chen,Huaimo]] It seems that time is critical here= .

 

[6] Merge point behavio= r

 

Detail about merge poin= t behavior:

How to distinguish prim= ary LSP and backup LSP;

How to handle and propa= gate ResvTear and PathErr received from downstream;

 

 

[[Chen,Huaimo]] Some details may be added in the ne= xt version.

 

Thanks,

 

-Yimin Shen<= /span>

 

Juniper Networks

 

 

 

 

Thanks,

 

-Yimin

 

 

 

 

--_000_5316A0AB3C851246A7CA5758973207D4325F6269dfweml505mbx_-- From huaimo.chen@huawei.com Sun Apr 8 18:19:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A7321F8570 for ; Sun, 8 Apr 2012 18:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9f-dUrVZD-6f for ; Sun, 8 Apr 2012 18:19:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C52B21F856A for ; Sun, 8 Apr 2012 18:19:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB21264; Sun, 08 Apr 2012 21:19:49 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Apr 2012 18:19:07 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Sun, 8 Apr 2012 18:18:44 -0700 From: Huaimo Chen To: Yimin Shen , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Thread-Topic: comments on draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac0Shf8u1K3w2DeITyaXdtWAFD/O9QDZbF2w Date: Mon, 9 Apr 2012 01:19:06 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D4325F6291@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.154.103] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D4325F6291dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 01:19:51 -0000 --_000_5316A0AB3C851246A7CA5758973207D4325F6291dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yimin, See my answers inline below. Best Regards, Huaimo -----Original Message----- From: Yimin Shen [mailto:yshen@juniper.net] Sent: Wednesday, April 04, 2012 1:12 PM To: draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: comments on draft-chen-mpls-p2mp-egress-protection Huaimo, As I commented during your presentation, the current draft only supports 1:= 1 protection. IOW, in order to protect X primary PEs, you would need X dedi= cated backup PEs. Therefore, from the perspective of cost efficiency, the d= raft may need to consider 1:N protection and "dual-role" PE (i.e. a primary= PE also serves as a backup PE for another primary PE). [[Chen,Huaimo]] One to one protection and one to many protection (or bypass= protection) are in our mind when we started our drafts. It may be better t= o have one thing at a time. OTOH, even with the current 1:1 protection, I see a more fundamental issue = with the following type of topology, where two primary PEs (i.e. their path= s) share the same penultimate hop router, and the paths to their backup PEs= share the same downstream link from the penultimate hop router. [[Chen,Huaimo]] Your assumption seems not true. Thus your conclusion is not= valid. We may have two primary PEs sharing the same penultimate hop node. = However, when we compute backup paths to their backup PEs, we will avoid th= e situation that the paths to their backup PEs share the same downstream li= nk from the penultimate hop node. Please see an example below. Assume a CE is dual-homed to PE-prim-1 and PE-= back-1, and another CE is dual-homed to PE-prim-2 and PE-back-2 (not shown = in the picture). If PE-prim-1 fails, P1 will turn on traffic towards P2, ho= ping the traffic to reach PE-back-1. However, not only PE-back-1 will recei= ve the traffic, but also PE-back-2 as well. This is because the path P1 -> = P2 -> PE-back-2 shares the link P1-P2 with the path P1 -> P2 ->PE-back-1. = Hence, the CE connected to PE-prim-2 and PE-back-2 will receive duplicate t= raffic from both PEs at the same time. I think the draft needs to address t= his kind problem. PE-in ---------- P1 ---------- PE-prim-1 | \---------- PE-prim-2 | | P2 ---------- PE-back-1 \---------- PE-back-2 Thanks, -Yimin Shen Juniper Networks --_000_5316A0AB3C851246A7CA5758973207D4325F6291dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yimin,
 
    See my answers inline below.
 
Best Regards,
Huaimo
-----Original Message-----
From: Yimin Shen [mailto:yshen@juniper= .net]
Sent: Wednesday, April 04, 2012 1:12 PM
To: draft-chen-mpls-p2mp-egress-protection@tools.ietf.org
Cc: mpls@ietf.org
Subject: comments on draft-chen-mpls-p2mp-egress-protection
 
Huaimo,
 
As I commented during your presentation, the current draft only suppor= ts 1:1 protection. IOW, in order to protect X primary PEs, you would need X= dedicated backup PEs. Therefore, from the perspective of cost efficiency, = the draft may need to consider 1:N protection and "dual-role" PE (i.e. a primary PE also serves as a= backup PE for another primary PE).
[[Chen,Huaimo]] One to= one protection and one to many protection (or bypass protection) are in ou= r mind when we started our drafts. It may be better to have one thing at a time.
 
OTOH, even with the current 1:1 protection, I see a more fundamental i= ssue with the following type of topology, where two primary PEs (i.e. their= paths) share the same penultimate hop router, and the paths to their backu= p PEs share the same downstream link from the penultimate hop router.
[[Chen,Huaimo]] Your a= ssumption seems not true. Thus your conclusion<= /i> is not valid. We may have two primary PEs sharing the same penultimate hop node. However, <= b>when we compute backup paths to their = backup PEs, we will avoid the situati= on that the paths to their backup PEs share the same downstream link from the penultimate hop= node.
 
Please see an example below. Assume a CE is dual-homed to PE-prim-1 an= d PE-back-1, and another CE is dual-homed to PE-prim-2 and PE-back-2 (not s= hown in the picture). If PE-prim-1 fails, P1 will turn on traffic towards P= 2, hoping the traffic to reach PE-back-1. However, not only PE-back-1 will receive the traffic, but also PE-back-2 as= well. This is because the path P1 -> P2 -> PE-back-2 shares the = ; link P1-P2 with the path P1 -> P2 ->PE-back-1. Hence, the CE connec= ted to PE-prim-2 and PE-back-2 will receive duplicate traffic from both PEs at the same time. I think the draft needs to address = this kind problem.
 
 
PE-in ---------- P1 ---------- PE-prim-1
           &nbs= p;     | \---------- PE-prim-2
           &nbs= p;     |
           &nbs= p;     |
           &nbs= p;     P2 ---------- PE-back-1
           &nbs= p;       \---------- PE-back-2
 
Thanks,
 
-Yimin Shen
Juniper Networks
 
 
 
 
 --_000_5316A0AB3C851246A7CA5758973207D4325F6291dfweml505mbx_-- From zhang.fei3@zte.com.cn Mon Apr 9 17:58:26 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6092121F877F for ; Mon, 9 Apr 2012 17:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubRoHQ9u3LZd for ; Mon, 9 Apr 2012 17:58:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE1921F8779 for ; Mon, 9 Apr 2012 17:58:25 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620806486374; Tue, 10 Apr 2012 08:20:51 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 58488.1509035444; Tue, 10 Apr 2012 08:58:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3A0wD5V004872; Tue, 10 Apr 2012 08:58:13 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: thomas.nadeau@ca.com, kkoushik@cisco.com, riza.cetin@alcatel.be, mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 10 Apr 2012 08:58:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-10 08:58:14, Serialize complete at 2012-04-10 08:58:14 Content-Type: multipart/alternative; boundary="=_alternative 00055364482579DC_=" X-MAIL: mse02.zte.com.cn q3A0wD5V004872 Subject: Re: [mpls] questions on RFC6445 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 00:58:26 -0000 This is a multipart message in MIME format. --=_alternative 00055364482579DC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTVBMU2Vycw0KDQpXZSBmZWVsICJ1bmNvbWZvcnRhYmxlIiB3aGVuIHdlIHJlYWQgdGhlIFJG QzY0NDUgc2luY2Ugc29tZSB0cml2aWFsIA0KZGVzY3JpcHRpb25zIGxpc3RlZCBpbiB0aGUgcHJl dmlvdXMgbWFpbCBjb25mdXNlIHVzLiANCg0KTWF5YmUgaXQgaXMgdG9vIG5haXZlIGZvciB1cyBi dXQgd2UgcmVhbGx5IG5lZWQgeW91IGhlbHAuICA6KQ0KDQpDYW4gYW55Ym9keSBzaGVkIHNvbWUg bGlnaHQgb24gdXM/DQoNClJlZ2FyZHMNCg0KRmVpDQoNCg0KDQpoZS53ZW5qdWFuMUB6dGUuY29t LmNuIA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTAzLTAyIDA5OjIyDQoN CsrVvP7Iyw0KdGhvbWFzLm5hZGVhdUBjYS5jb20sIGtrb3VzaGlrQGNpc2NvLmNvbSwgcml6YS5j ZXRpbkBhbGNhdGVsLmJlDQqzrcvNDQptcGxzQGlldGYub3JnDQrW98ziDQpbbXBsc10gcXVlc3Rp b25zIG9uIFJGQzY0NDUNCg0KDQoNCg0KDQoNCg0KSGkgYXV0aG9ycyAmIG90aGVycywgDQoNCkkg aGF2ZSBzb21lIHF1ZXN0aW9ucyBvbiBSRkM2NDQ1LCBzZWUgYmVsb3csIA0KDQoNCjEsSW4gc2Vj dGlvbiA0LjIuMzogDQogICAgICAiIG1wbHNGcnJPbmUyT25lUGxyVHVubmVsRGV0b3VySW5zdGFu Y2UgID0gNjU1MzYwMSwgDQogICAgICAgLS0gDQogICAgICAgLS0gKDEwMCA8PCAxNiB8IDEpID09 IDY1NTM2MDEgDQoNCiAgICAgICAtLSAxIGlzIG1wbHNUdW5uZWxJbnN0YW5jZSBmb3IgdGhlIGRl dG91ciBMU1AgDQogICAgICAgLS0gZnJvbSBtcGxzVHVubmVsVGFibGUuICBNYXJrZWQgYnkgQUFB IGJlbG93LiANCiAgICAgICAtLSBTaGlmdCAxNiB0byBwdXQgdGhpcyBpbnRvIHRoZSBoaWdoLW9y ZGVyIGJpdHMgDQogDQogICAgICAgLS0gMTAwIGlzIG1wbHNUdW5uZWxJbnN0YW5jZSBmb3IgdGhl IHByb3RlY3RlZCB0dW5uZWwgDQogICAgICAgLS0gZnJvbSB0aGUgbXBsc1R1bm5lbFRhYmxlLiAg TWFya2VkIGJ5IEJCQiBiZWxvdy4gDQogICAgICAgLS0gTmVlZCB0byBPUiB0aGUgaW5kZXggdmFs dWUgaW50byBsb3ctb3JkZXIgYml0cykiIA0KICAgIA0KW1dlbmp1YW5dVGhpcyBkZXNjcmlwdGlv biBpcyBjb25mdXNpbmcsIHdoaWNoIGlzIG5vdCBjb25zaXN0ZW50IHdpdGggDQpkZWZpbml0aW9u IG9mIHRoZSBtcGxzRnJyT25lMk9uZVBsclR1bm5lbERldG91ckluc3RhbmNlKCgxMDAgPDwgMTYg fCAxKSA9PSANCjY1NTM2MDEpLiANCkluIHRoZSBzZWN0aW9uIGJlbG93LCB0aGUgbXBsc1R1bm5l bEluc3RhbmNlICgxMDApIGZvciB0aGUgcHJvdGVjdGVkIA0KdHVubmVsIGlzIG1hcmtlZCBieSBB QUEgaW4gbXBsc1R1bm5lbFRhYmxlKHByb3RlY3RlZCB0dW5uZWwgZW50cnkpLCB3aGljaCANCnNo b3VsZCBiZSBpbiANCnRoZSBoaWdoLW9yZGVyIGJpdHMuICAgDQogICAgICAgICAgICAgIA0KDQoy LEluIG1wbHNUdW5uZWxUYWJsZSAoZGV0b3VyIExTUCBlbnRyeSk6IA0KDQogICAgICIgbXBsc1R1 bm5lbEluZGV4ICAgICAgICAgICAgICA9IDEsIA0KICAgICAgbXBsc1R1bm5lbEluc3RhbmNlICAg ICAgICAgICA9IDEsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBJbmRpY2F0aW5n IGRldG91ciBMU1AgKGhpZ2hlciAxNiBiaXRzKSANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLS0gQkJCICIgDQoNCltXZW5qdWFuXVRoZSBkZXRvdXIgbHNwIGFuZCB0aGUgcHJvdGVjdGVk IGxzcCBoYXZlIHRoZSBzYW1lIA0KSW5ncmVzc0xTUklkLEVncmVzc0xTUklkLFR1bm5lbEluZGV4 IGFuZCB0aGUgbXBsc1R1bm5lbEluc3RhbmNlLCBzZWUgdGhlIA0KcGF0aC1zcGVjaWZpYyBtZXRo b2QgaW4gdGhlIFJGQzQwOTAuIA0KSW4gdGhpcyBkb2N1bWVudCwgdGhlIG1wbHNUdW5uZWxJbnN0 YW5jZSBmb3IgdGhlIGRldG91ciBsc3AgaXMgZGlmZmVyZW50IA0Kd2l0aCBwcm90ZWN0ZWQgdHVu bmVsIGluc3RhbmNlLkkgZGlkIG5vdCBmaW5kIGFueSBvdGhlciBkZXNjcmlwdGlvbiBhYm91dCAN CnRoaXMgaW5zdGFuY2UgaW4gdGhlIGRyYWZ0LiANCkNvdWxkIHlvdSBtYWtlIHNvbWUgY2xhcmlm aWNhdGlvbnMgYWJvdXQgdGhpcyBtcGxzVHVubmVsSW5zdGFuY2UgZm9yIHRoZSANCmRldG91ciBs c3A/IA0KDQozLCANCiAgICAgICJtcGxzVHVubmVsSW5ncmVzc0xTUklkICAgICAgID0gMTkyLjAu Mi4xLCANCiAgICAgICBtcGxzVHVubmVsRWdyZXNzTFNSSWQgICAgICAgID0gMTkyLjAuMi4zLCAi IA0KDQpbV2VuanVhbl06aW4gdGhpcyBkb2N1bWVudCx0aGUgZGV0b3VyIGxzcCdzIEVncmVzc0xT UklkIGlzIHRoZSBhZGRyZXNzIG9mIA0KdGhlIG1lcmdlZCBwb2ludChSMykuIFRoaXMgZGVzY3Jp cHRpb24gaXMgbm90IGNvbnNpc3RlbnQgd2l0aCB0aGUgc2VjdGlvbiANCjYuMyBvZiB0aGUgUkZD NDA5MC4gDQpUaGUgRWdyZXNzTFNSSWQgb2YgdGhlIGRldG91ciBsc3AgaXMgc2FtZSB3aXRoIHRo ZSBwcm90ZWN0ZWQgdHVubmVsIGluIHRoZSANClJGQzQwOTAuIA0KDQoNClRoYW5rcyANCldlbmp1 YW5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBt YWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbXBscw0KDQoNCg== --=_alternative 00055364482579DC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE1QTFNlcnM8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlIGZlZWwgJnF1b3Q7dW5j b21mb3J0YWJsZSZxdW90OyB3aGVuDQp3ZSByZWFkIHRoZSBSRkM2NDQ1IHNpbmNlIHNvbWUgdHJp dmlhbCBkZXNjcmlwdGlvbnMgbGlzdGVkIGluIHRoZSBwcmV2aW91cw0KbWFpbCBjb25mdXNlIHVz LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1heWJl IGl0IGlzIHRvbyBuYWl2ZSBmb3IgdXMgYnV0IHdlDQpyZWFsbHkgbmVlZCB5b3UgaGVscC4gJm5i c3A7Oik8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNh biBhbnlib2R5IHNoZWQgc29tZSBsaWdodCBvbiB1cz88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5oZS53ZW5qdWFuMUB6dGUuY29tLmNuPC9iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO21w bHMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEyLTAzLTAyIDA5OjIyPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnRob21hcy5uYWRlYXVAY2EuY29tLCBra291c2hpa0BjaXNj by5jb20sDQpyaXphLmNldGluQGFsY2F0ZWwuYmU8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm1wbHNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlttcGxzXSBxdWVzdGlvbnMgb24gUkZDNjQ0NTwvZm9u dD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90 YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpIaSBhdXRob3JzICZhbXA7IG90aGVycyw8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkg aGF2ZSBzb21lIHF1ZXN0aW9ucyBvbiBSRkM2NDQ1LCBzZWUgYmVsb3csPC9mb250Pjxmb250IHNp emU9Mz4gPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQoxLEluIHNlY3Rpb24gNC4yLjM6PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVv dDsgbXBsc0Zyck9uZTJPbmVQbHJUdW5uZWxEZXRvdXJJbnN0YW5jZSAmbmJzcDs9DQo2NTUzNjAx LDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tPC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgLS0gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0ic2Fucy1zZXJpZiI+ KDEwMA0KJmx0OyZsdDsgMTYgfCAxKSA9PSA2NTUzNjAxPC9mb250Pjxmb250IHNpemU9Mz4gPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgLS0gMSBpcyBtcGxzVHVubmVsSW5zdGFuY2UgZm9yIHRoZSBkZXRvdXIgTFNQ PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIGZyb20gbXBsc1R1bm5lbFRhYmxlLiAm bmJzcDtNYXJrZWQgYnkgQUFBIGJlbG93LjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt LSBTaGlmdCAxNiB0byBwdXQgdGhpcyBpbnRvIHRoZSBoaWdoLW9yZGVyIGJpdHMNCjxicj4NCiAm bmJzcDs8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0gMTAwIGlzIG1wbHNUdW5uZWxJbnN0 YW5jZSBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJz cDsgLS0gZnJvbSB0aGUgbXBsc1R1bm5lbFRhYmxlLiAmbmJzcDtNYXJrZWQgYnkgQkJCDQpiZWxv dy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAtLSBOZWVkIHRvIE9SIHRoZSBpbmRleCB2 YWx1ZSBpbnRvIGxvdy1vcmRlciBiaXRzKSZxdW90OzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgPC9mb250Pjxm b250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCltXZW5qdWFuXVRoaXMgZGVzY3JpcHRpb24gaXMgY29uZnVzaW5nLCB3aGljaCBpcyBub3Qg Y29uc2lzdGVudCB3aXRoIGRlZmluaXRpb24NCm9mIHRoZSBtcGxzRnJyT25lMk9uZVBsclR1bm5l bERldG91ckluc3RhbmNlKDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9InNhbnMt c2VyaWYiPigxMDANCiZsdDsmbHQ7IDE2IHwgMSkgPT0gNjU1MzYwMTwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+KS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJbiB0aGUgc2VjdGlvbiBiZWxvdywgdGhl IG1wbHNUdW5uZWxJbnN0YW5jZSAoMTAwKSBmb3IgdGhlIHByb3RlY3RlZCB0dW5uZWwNCmlzIG1h cmtlZCBieSBBQUEgaW4gbXBsc1R1bm5lbFRhYmxlKHByb3RlY3RlZCB0dW5uZWwgZW50cnkpLCB3 aGljaCBzaG91bGQNCmJlIGluIDxicj4NCnRoZSBoaWdoLW9yZGVyIGJpdHMuICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQoyLEluIG1wbHNUdW5uZWxUYWJsZSAoZGV0b3VyIExTUCBlbnRyeSk6PC9mb250Pjxm b250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48 YnI+DQogJm5ic3A7ICZuYnNwOyAmcXVvdDsgbXBsc1R1bm5lbEluZGV4ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs9IDEsPC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDttcGxzVHVubmVsSW5zdGFuY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KPSAxLDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IC0tIEluZGljYXRpbmcgZGV0b3VyIExTUCAoaGlnaGVyIDE2IGJpdHMpPC9mb250Pjxm b250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC0tIEJCQiAmcXVvdDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCltXZW5qdWFuXVRoZSBkZXRvdXIgbHNwIGFuZCB0aGUgcHJvdGVjdGVkIGxz cCBoYXZlIHRoZSBzYW1lIEluZ3Jlc3NMU1JJZCxFZ3Jlc3NMU1JJZCxUdW5uZWxJbmRleA0KYW5k IHRoZSBtcGxzVHVubmVsSW5zdGFuY2UsIHNlZSB0aGUgcGF0aC1zcGVjaWZpYyBtZXRob2QgaW4g dGhlIFJGQzQwOTAuPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KSW4gdGhpcyBkb2N1bWVudCwgdGhlIG1wbHNUdW5uZWxJbnN0 YW5jZSBmb3IgdGhlIGRldG91ciBsc3AgaXMgZGlmZmVyZW50DQp3aXRoIHByb3RlY3RlZCB0dW5u ZWwgaW5zdGFuY2UuSSBkaWQgbm90IGZpbmQgYW55IG90aGVyIGRlc2NyaXB0aW9uIGFib3V0DQp0 aGlzIGluc3RhbmNlIGluIHRoZSBkcmFmdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkNvdWxkIHlvdSBtYWtlIHNvbWUgY2xh cmlmaWNhdGlvbnMgYWJvdXQgdGhpcyBtcGxzVHVubmVsSW5zdGFuY2UgZm9yIHRoZQ0KZGV0b3Vy IGxzcD88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCjMsICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDttcGxzVHVubmVsSW5ncmVzc0xTUklkICZuYnNwOyAm bmJzcDsgJm5ic3A7DQo9IDE5Mi4wLjIuMSw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBt cGxzVHVubmVsRWdyZXNzTFNSSWQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PQ0KMTkyLjAu Mi4zLCAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCltXZW5qdWFuXTppbiB0aGlzIGRvY3VtZW50LHRoZSBk ZXRvdXIgbHNwJ3MgRWdyZXNzTFNSSWQgaXMgdGhlIGFkZHJlc3MNCm9mIHRoZSBtZXJnZWQgcG9p bnQoUjMpLiBUaGlzIGRlc2NyaXB0aW9uIGlzIG5vdCBjb25zaXN0ZW50IHdpdGggdGhlIHNlY3Rp b24NCjYuMyBvZiB0aGUgUkZDNDA5MC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoZSBFZ3Jlc3NMU1JJZCBvZiB0aGUgZGV0 b3VyIGxzcCBpcyBzYW1lIHdpdGggdGhlIHByb3RlY3RlZCB0dW5uZWwgaW4NCnRoZSBSRkM0MDkw LjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KVGhhbmtzIDxicj4NCldlbmp1YW48L2ZvbnQ+PHR0Pjxmb250 IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCm1wbHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 00055364482579DC_=-- From adrian@olddog.co.uk Tue Apr 10 13:12:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546EB21F850C; Tue, 10 Apr 2012 13:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrqdyRV-iknh; Tue, 10 Apr 2012 13:12:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 2629921F8501; Tue, 10 Apr 2012 13:12:52 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3AKCp3m011940; Tue, 10 Apr 2012 21:12:51 +0100 Received: from 950129200 (AGrenoble-551-1-43-107.w92-157.abo.wanadoo.fr [92.157.202.107]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3AKCnJE011920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 21:12:50 +0100 From: "Adrian Farrel" To: References: <20120410200214.21728.80545.idtracker@ietfa.amsl.com> In-Reply-To: <20120410200214.21728.80545.idtracker@ietfa.amsl.com> Date: Tue, 10 Apr 2012 21:12:50 +0100 Message-ID: <110101cd1756$4f01b270$ed051750$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIF569mwn8deiFiORYDjqgwh+Kp2ZYi3HdQ Content-Language: en-gb Cc: mpls@ietf.org, pwe3@ietf.org Subject: [mpls] FW: New Version Notification - draft-betts-itu-oam-ach-code-point-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 20:12:55 -0000 Hi, Malcolm has been busy working on a new version of this I-D to address = the issues and comments raised during IETF last call. I have had a look at the changes (and supplied some suggestions) as = sponsoring AD. I think that this version is a pretty fine attempt at = addressing the concerns. Please hang in there while we put together some emails to explain the = changes and respond to the specific concerns that were raised. Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 10 April 2012 21:02 > To: malcolm.betts@zte.com.cn; draft-betts-itu-oam-ach-code- > point@tools.ietf.org; Huub.van.Helvoort@huawei.com; = adrian@olddog.co.uk > Subject: New Version Notification - = draft-betts-itu-oam-ach-code-point-04.txt >=20 > New version (-04) has been submitted for = draft-betts-itu-oam-ach-code-point- > 04.txt: > = http://www.ietf.org/internet-drafts/draft-betts-itu-oam-ach-code-point-04= .txt >=20 > Diff from previous version: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-betts-itu-oam-ach-code-point-0= 4 >=20 > IETF Secretariat. From fu.xihua@zte.com.cn Wed Apr 11 00:30:32 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFDD21F85CD for ; Wed, 11 Apr 2012 00:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ozExOweQd8T for ; Wed, 11 Apr 2012 00:30:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5F21F85B1 for ; Wed, 11 Apr 2012 00:30:31 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620806486374; Wed, 11 Apr 2012 14:52:44 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 56334.806486374; Wed, 11 Apr 2012 15:30:15 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3B7UGoZ030156 for ; Wed, 11 Apr 2012 15:30:16 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <20120411071230.24757.2146.idtracker@ietfa.amsl.com> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Wed, 11 Apr 2012 15:30:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-11 15:30:19, Serialize complete at 2012-04-11 15:30:19 Content-Type: multipart/alternative; boundary="=_alternative 002939CB482579DD_=" X-MAIL: mse02.zte.com.cn q3B7UGoZ030156 Subject: Re: [mpls] I-D Action: draft-fuxh-mpls-delay-loss-te-framework-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 07:30:32 -0000 This is a multipart message in MIME format. --=_alternative 002939CB482579DD_= Content-Type: text/plain; charset="US-ASCII" Hi All, This draft is a framework for delay and loss TE including tracking the various solution approaches. We updated the draft to 05 version. There is a little bit chang in this version including the following references with citations in section "6. Protocol Considerations". http://tools.ietf.org/id/draft-ietf-ospf-te-metric-extensions-00.txt http://tools.ietf.org/id/draft-previdi-isis-te-metric-extensions-01.txt http://tools.ietf.org/id/draft-fuxh-mpls-delay-loss-rsvp-te-ext-01.txt http://tools.ietf.org/html/draft-atlas-mpls-te-express-path-00 We add some sentences to senction "2.5.Restoration, Protection and Rerouting" to resolve the comments about relative time management from Masa DAIKOKU (KDDI) and included the MPLS-TP USE CASE reference. http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-01 We think it is a stable version before WG doc adoption. Any comments are welcome and appreciated. Best Regards, Authors > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Loss and Delay Traffic Engineering Framework for MPLS > Author(s) : Xihua Fu > Vishwas Manral > Dave McDysan > Andrew Malis > Spencer Giacalone > Malcolm Betts > Qilei Wang > John Drake > Filename : draft-fuxh-mpls-delay-loss-te-framework-05.txt > Pages : 15 > Date : 2012-04-11 > > With more and more enterprises using cloud based services, the > distances between the user and the applications are growing. A lot > of the current applications are designed to work across LAN's and > have various inherent assumptions. For multiple applications such as > High Performance Computing and Electronic Financial markets, the > response times are critical as is packet loss, while other > applications require more throughput. > > [RFC3031] describes the architecture of MPLS based networks. This > draft extends the MPLS architecture to allow for latency, loss and > jitter as properties. It describes requirements and control plane > implication for latency and packet loss as a traffic engineering > performance metric in today's network which is consisting of > potentially multiple layers of packet transport network and optical > transport network in order to make a accurate end-to-end latency and > loss prediction before a path is established. > > Note MPLS architecture for Multicast will be taken up in a future > version of the draft. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > framework-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > framework-05.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > --=_alternative 002939CB482579DD_= Content-Type: text/html; charset="US-ASCII"
Hi All,

This draft is a framework for delay and loss TE including  tracking the various solution approaches.
We updated the draft to 05 version. There is a little bit chang in this version including the following references with citations in section "6. Protocol Considerations".
http://tools.ietf.org/id/draft-ietf-ospf-te-metric-extensions-00.txt
http://tools.ietf.org/id/draft-previdi-isis-te-metric-extensions-01.txt
http://tools.ietf.org/id/draft-fuxh-mpls-delay-loss-rsvp-te-ext-01.txt
http://tools.ietf.org/html/draft-atlas-mpls-te-express-path-00
We add some sentences to senction "2.5.Restoration, Protection and Rerouting" to resolve the comments about relative time management from Masa DAIKOKU (KDDI) and included the MPLS-TP USE CASE reference.
http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-01
We think it is a stable version before WG doc adoption. Any comments are welcome and appreciated.

Best Regards,

Authors

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title           : Loss and Delay Traffic Engineering Framework for MPLS
>    Author(s)       : Xihua Fu
>                           Vishwas Manral
>                           Dave McDysan
>                           Andrew Malis
>                           Spencer Giacalone
>                           Malcolm Betts
>                           Qilei Wang
>                           John Drake
>    Filename        : draft-fuxh-mpls-delay-loss-te-framework-05.txt
>    Pages           : 15
>    Date            : 2012-04-11
>
>    With more and more enterprises using cloud based services, the
>    distances between the user and the applications are growing.  A lot
>    of the current applications are designed to work across LAN's and
>    have various inherent assumptions.  For multiple applications such as
>    High Performance Computing and Electronic Financial markets, the
>    response times are critical as is packet loss, while other
>    applications require more throughput.
>
>    [RFC3031] describes the architecture of MPLS based networks.  This
>    draft extends the MPLS architecture to allow for latency, loss and
>    jitter as properties.  It describes requirements and control plane
>    implication for latency and packet loss as a traffic engineering
>    performance metric in today's network which is consisting of
>    potentially multiple layers of packet transport network and optical
>    transport network in order to make a accurate end-to-end latency and
>    loss prediction before a path is established.
>
>    Note MPLS architecture for Multicast will be taken up in a future
>    version of the draft.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-
> framework-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te-
> framework-05.txt
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
--=_alternative 002939CB482579DD_=-- From loa@pi.nu Wed Apr 11 01:40:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A567711E814C for ; Wed, 11 Apr 2012 01:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+TSof+BJ2yk for ; Wed, 11 Apr 2012 01:40:37 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id A503D11E814A for ; Wed, 11 Apr 2012 01:40:37 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 57C142A8002; Wed, 11 Apr 2012 10:40:35 +0200 (CEST) Message-ID: <4F854382.4020909@pi.nu> Date: Wed, 11 Apr 2012 10:40:34 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "rtg-ads@tools.ietf.org" References: <4F61C551.8070009@pi.nu> <4F61DE8C.3000802@pi.nu> In-Reply-To: <4F61DE8C.3000802@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:40:38 -0000 Working Group, this working group last call has ended. Could the authors please publish a new version of the document! /Loa for the MPLS wg co-chairs On 2012-03-15 13:20, Loa Andersson wrote: > > > Working Group, > > (slight change of the subject, please use this one to send lc comments). > > This is to start a working group last call on > draft-ietf-mpls-ldp-gtsm-04. > > Normally we do two week wg last calls, but since this is across the > IETF meeting in Paris we make it a week longer. > > The working group last call ends eob Friday April 6 2012. > > Please send comments to the mpls working group mailing list > (mpls@ietf.org). > > /Loa > for the MPLS WG co-chairs > > PS > There are nit warnings depending on that draft were published last > year and that one of the references has been updated, no need to report > that. > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From internet-drafts@ietf.org Wed Apr 11 06:53:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C111E8168; Wed, 11 Apr 2012 06:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWL0GlFzrjkU; Wed, 11 Apr 2012 06:53:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF96C11E8159; Wed, 11 Apr 2012 06:53:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120411135336.28063.4457.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 06:53:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-gtsm-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:53:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : The Generalized TTL Security Mechanism (GTSM) for Label = Distribution Protocol (LDP) Author(s) : Carlos Pignataro Rajiv Asati Filename : draft-ietf-mpls-ldp-gtsm-05.txt Pages : 9 Date : 2012-04-11 The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-ldp-gtsm-05.txt From cpignata@cisco.com Wed Apr 11 06:54:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5307311E8179 for ; Wed, 11 Apr 2012 06:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGzbNwADpm6l for ; Wed, 11 Apr 2012 06:54:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B791911E8178 for ; Wed, 11 Apr 2012 06:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=2122; q=dns/txt; s=iport; t=1334152441; x=1335362041; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=NDj0DIF6qh8VxX1DU8BUtHwHzL2fF/3L0xh+3IRHZGU=; b=YmHqMJtFI60H9XL5n79mbYf6EgvkNGv/e81Atsys8GmzY4qdCRDd/cJU 3cuk1skcEZ0TJGRHnJe+dIf1FWPhk2fSvzoimgWJK3OQ/UD/wstznpDTn 6IAYMk9RhzeVIJ4+bRomD8C863yAr5fktaCIctRmqwyWU8gCLXVdfZGe0 s=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAB2MhU+rRDoG/2dsb2JhbABDuVuBB4IJAQEBAwEBAQEPAVsLBQkCCxguGwwwBhMih2cEAQufCJhDBASQX2MEjmyHAI5NgWmDA4FA X-IronPort-AV: E=Sophos;i="4.75,406,1330905600"; d="asc'?scan'208";a="39928228" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Apr 2012 13:54:01 +0000 Received: from dhcp-64-102-209-109.cisco.com (dhcp-64-102-209-109.cisco.com [64.102.209.109]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3BDs0qa020618; Wed, 11 Apr 2012 13:54:01 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3BB6670D-D3B0-4090-8643-755B561CAA08"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: <4F854382.4020909@pi.nu> Date: Wed, 11 Apr 2012 09:54:00 -0400 Message-Id: <470E8513-91C4-48CF-A58C-9EFCE4916D2E@cisco.com> References: <4F61C551.8070009@pi.nu> <4F61DE8C.3000802@pi.nu> <4F854382.4020909@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-ietf-mpls-ldp-gtsm@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-ldp-gtsm-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 13:54:02 -0000 --Apple-Mail=_3BB6670D-D3B0-4090-8643-755B561CAA08 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Loa, On Apr 11, 2012, at 4:40 AM, Loa Andersson wrote: > Working Group, > > this working group last call has ended. Could the authors please > publish a new version of the document! > Done. Thanks. -- Carlos. > /Loa > for the MPLS wg co-chairs > > On 2012-03-15 13:20, Loa Andersson wrote: >> >> >> Working Group, >> >> (slight change of the subject, please use this one to send lc comments). >> >> This is to start a working group last call on >> draft-ietf-mpls-ldp-gtsm-04. >> >> Normally we do two week wg last calls, but since this is across the >> IETF meeting in Paris we make it a week longer. >> >> The working group last call ends eob Friday April 6 2012. >> >> Please send comments to the mpls working group mailing list >> (mpls@ietf.org). >> >> /Loa >> for the MPLS WG co-chairs >> >> PS >> There are nit warnings depending on that draft were published last >> year and that one of the references has been updated, no need to report >> that. >> >> > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --Apple-Mail=_3BB6670D-D3B0-4090-8643-755B561CAA08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk+FjPgACgkQtfDPGTp3USzC6QCeNVpjsx2fRGO9zSH2GYPx4Ip0 GTMAni9x+Ai21OaC+b4pWSfC9O/6GCzR =ku3s -----END PGP SIGNATURE----- --Apple-Mail=_3BB6670D-D3B0-4090-8643-755B561CAA08-- From vishwas.ietf@gmail.com Wed Apr 11 08:08:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E2811E80B6 for ; Wed, 11 Apr 2012 08:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vuqow3OzxBcX for ; Wed, 11 Apr 2012 08:08:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2C11E80AA for ; Wed, 11 Apr 2012 08:08:51 -0700 (PDT) Received: by ghbg16 with SMTP id g16so558381ghb.31 for ; Wed, 11 Apr 2012 08:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0ROoB0PhxVBJBZtPKZbXL8EZlFg3M4vq4yC1+2bzBpI=; b=QLC7q0zTgBAdMQtmCTt8if0tSRLDFeO1A97i17ROlmXDSYtwxCSXSfJGgkJbgXPqs0 mqBQMNok3KqW21R653RlNGKF2LdD7T+o6IoNfE+mjCuDeqdM8EfIO2JTGSoAHUQlWu5y kHe261qg7lmfapnzJrzDn6HNgyKF48OByiC7KnvbNljqP7rUmNUlpKNCXuqEqut1CP/I 7nrCAVmhQpKvT+Jdg9CI8dpVvN+3+/5CWT696u13AUNUXoY/oiecsDTr2YLe25UkEu+A 4OlDVjI6Yv0HPOWnu92W/oPIUF/DEkjx81E6qI0n8+0mhcL/P5t9oodyWKDqQLKkNg5I rY7Q== MIME-Version: 1.0 Received: by 10.60.28.103 with SMTP id a7mr22738300oeh.24.1334156931350; Wed, 11 Apr 2012 08:08:51 -0700 (PDT) Received: by 10.182.171.65 with HTTP; Wed, 11 Apr 2012 08:08:51 -0700 (PDT) In-Reply-To: References: <20120411071230.24757.2146.idtracker@ietfa.amsl.com> Date: Wed, 11 Apr 2012 08:08:51 -0700 Message-ID: From: Vishwas Manral To: fu.xihua@zte.com.cn Content-Type: multipart/alternative; boundary=e89a8ff1cafaf7c0d704bd689d09 Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action: draft-fuxh-mpls-delay-loss-te-framework-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:08:53 -0000 --e89a8ff1cafaf7c0d704bd689d09 Content-Type: text/plain; charset=ISO-8859-1 Thanks Fu, Just to add, I think there is another reference in the bundle we can use for PCE: http://tools.ietf.org/html/draft-dhody-pce-pcep-service-aware-02 Thanks, Vishwas On Wed, Apr 11, 2012 at 12:30 AM, wrote: > > Hi All, > > This draft is a framework for delay and loss TE including tracking the > various solution approaches. > We updated the draft to 05 version. There is a little bit chang in this > version including the following references with citations in section "6. > Protocol Considerations". > *http://tools.ietf.org/id/draft-ietf-ospf-te-metric-extensions-00.txt* > *http://tools.ietf.org/id/draft-previdi-isis-te-metric-extensions-01.txt* > *http://tools.ietf.org/id/draft-fuxh-mpls-delay-loss-rsvp-te-ext-01.txt* > *http://tools.ietf.org/html/draft-atlas-mpls-te-express-path-00* > We add some sentences to senction "2.5.Restoration, Protection and > Rerouting" to resolve the comments about relative time management from Masa > DAIKOKU (KDDI) and included the MPLS-TP USE CASE reference. > *http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-01* > We think it is a stable version before WG doc adoption. Any comments are > welcome and appreciated. > > Best Regards, > > Authors > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Loss and Delay Traffic Engineering Framework for > MPLS > > Author(s) : Xihua Fu > > Vishwas Manral > > Dave McDysan > > Andrew Malis > > Spencer Giacalone > > Malcolm Betts > > Qilei Wang > > John Drake > > Filename : draft-fuxh-mpls-delay-loss-te-framework-05.txt > > Pages : 15 > > Date : 2012-04-11 > > > > With more and more enterprises using cloud based services, the > > distances between the user and the applications are growing. A lot > > of the current applications are designed to work across LAN's and > > have various inherent assumptions. For multiple applications such as > > High Performance Computing and Electronic Financial markets, the > > response times are critical as is packet loss, while other > > applications require more throughput. > > > > [RFC3031] describes the architecture of MPLS based networks. This > > draft extends the MPLS architecture to allow for latency, loss and > > jitter as properties. It describes requirements and control plane > > implication for latency and packet loss as a traffic engineering > > performance metric in today's network which is consisting of > > potentially multiple layers of packet transport network and optical > > transport network in order to make a accurate end-to-end latency and > > loss prediction before a path is established. > > > > Note MPLS architecture for Multicast will be taken up in a future > > version of the draft. > > > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > > framework-05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpls-delay-loss-te- > > framework-05.txt > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --e89a8ff1cafaf7c0d704bd689d09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Fu,

Just to add, I think there is another reference in the bu= ndle we can use for PCE:
http://tools.ietf.org/html/draft-dhody-pce-pc= ep-service-aware-02

Thanks,
Vishwas

On Wed, Apr 11, 20= 12 at 12:30 AM, <fu.xihua@zte.com.cn> wrote:

Hi All,

This draft is a framework for delay and loss TE including =A0tracking the various solution approaches.
We updated the draft to 05 version. There is a little bit chang in this version including the following references with citations in section "6. Protocol Considerations".
http:/= /tools.ietf.org/id/draft-ietf-ospf-te-metric-extensions-00.txt
htt= p://tools.ietf.org/id/draft-previdi-isis-te-metric-extensions-01.txt
http= ://tools.ietf.org/id/draft-fuxh-mpls-delay-loss-rsvp-te-ext-01.txt
http://tools= .ietf.org/html/draft-atlas-mpls-te-express-path-00
We add some sentences to senction "2.5.Rest= oration, Protection and Rerouting" to resolve the comments about relative time management from Masa DAIKOKU (KDDI) and included the MPLS-TP USE CASE refer= ence.
http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-01=
We think it is a stable version before WG doc adoption. Any comments are welcome and appreciated.

Best Regards,

Authors

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Loss and Delay Traffic Engineering Framework for MPLS
> =A0 =A0Author(s) =A0 =A0 =A0 : Xihua Fu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Vishwas Manral
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Dave McDysan
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Andrew Malis
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Spencer Giacalone
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Malcolm Betts
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Qilei Wang
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Drake
> =A0 =A0Filename =A0 =A0 =A0 =A0: draft-fuxh-mpls-delay-loss-te-framewo= rk-05.txt
> =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 15
> =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-11
>
> =A0 =A0With more and more enterprises using cloud based services, the
> =A0 =A0distances between the user and the applications are growing. =A0A lot
> =A0 =A0of the current applications are designed to work across LAN's and
> =A0 =A0have various inherent assumptions. =A0For multiple applications such as
> =A0 =A0High Performance Computing and Electronic Financial markets, the
> =A0 =A0response times are critical as is packet loss, while other
> =A0 =A0applications require more throughput.
>
> =A0 =A0[RFC3031] describes the architecture of MPLS based networks. =A0This
> =A0 =A0draft extends the MPLS architecture to allow for latency, loss and
> =A0 =A0jitter as properties. =A0It describes requirements and control plane
> =A0 =A0implication for latency and packet loss as a traffic engineering
> =A0 =A0performance metric in today's network which is consisting of
> =A0 =A0potentially multiple layers of packet transport network and optical
> =A0 =A0transport network in order to make a accurate end-to-end latency and
> =A0 =A0loss prediction before a path is established.
>
> =A0 =A0Note MPLS architecture for Multicast will be taken up in a future
> =A0 =A0version of the draft.
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fuxh-m= pls-delay-loss-te-
> framework-05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-fuxh-mpl= s-delay-loss-te-
> framework-05.txt
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announc= e@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--e89a8ff1cafaf7c0d704bd689d09-- From yshen@juniper.net Wed Apr 11 14:55:33 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022C211E80BB for ; Wed, 11 Apr 2012 14:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P69kRFmB-h32 for ; Wed, 11 Apr 2012 14:55:32 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 74C8221F8470 for ; Wed, 11 Apr 2012 14:55:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT4X9yi0YYDC2EfOcZaM/eyUyu2vodvwi@postini.com; Wed, 11 Apr 2012 14:55:31 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Apr 2012 14:54:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 11 Apr 2012 17:54:19 -0400 From: Yimin Shen To: Huaimo Chen , "draft-chen-mpls-p2mp-egress-protection@tools.ietf.org" Date: Wed, 11 Apr 2012 17:54:15 -0400 Thread-Topic: comments on draft-chen-mpls-p2mp-egress-protection Thread-Index: Ac0Shf8u1K3w2DeITyaXdtWAFD/O9QDZbF2wAI0StCA= Message-ID: References: <5316A0AB3C851246A7CA5758973207D4325F6291@dfweml505-mbx> In-Reply-To: <5316A0AB3C851246A7CA5758973207D4325F6291@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-chen-mpls-p2mp-egress-protection X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:55:33 -0000 Huaimo, [[Chen,Huaimo]] One to one protection and one to many protection (or bypass= protection) are in our mind when we started our drafts. It may be better t= o have one thing at a time. I think 1:N protection is eventually needed due to its efficiency, flexibil= ity and scalability. It also covers 1:1 protection as a special case. Howev= er, your current 1:1 solution doesn't seem to be extendable to support 1:N.= So my concern is if there is a solution for 1:N in the future, it would be= a different approach than this draft. Why would we need this 1:1 specific = draft now? =20 [[Chen,Huaimo]] Your assumption seems not true. Thus your conclusion is not= valid. We may have two primary PEs sharing the same penultimate hop node. = However, when we compute backup paths to their backup PEs, we will avoid th= e situation that the paths to their backup PEs share the same downstream li= nk from the penultimate hop node. The draft needs to discuss the detail about how to detect and avoid the sit= uation in backup path computation. IMO, you would hit the same situation if= two backup paths share a link in common, regardless of whether they share = a same PLR or not. Thanks, -Yimin From: Huaimo Chen [mailto:huaimo.chen@huawei.com]=20 Sent: Sunday, April 08, 2012 9:19 PM To: Yimin Shen; draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: RE: comments on draft-chen-mpls-p2mp-egress-protection=20 Hi Yimin, =A0 =A0=A0=A0 See my answers inline below. =A0 Best Regards, Huaimo -----Original Message----- From: Yimin Shen [mailto:yshen@juniper.net]=20 Sent: Wednesday, April 04, 2012 1:12 PM To: draft-chen-mpls-p2mp-egress-protection@tools.ietf.org Cc: mpls@ietf.org Subject: comments on draft-chen-mpls-p2mp-egress-protection=20 =A0 Huaimo,=20 =A0 As I commented during your presentation, the current draft only supports 1:= 1 protection. IOW, in order to protect X primary PEs, you would need X dedi= cated backup PEs. Therefore, from the perspective of cost efficiency, the d= raft may need to consider 1:N protection and "dual-role" PE (i.e. a primary= PE also serves as a backup PE for another primary PE). [[Chen,Huaimo]] One to one protection and one to many protection (or bypass= protection) are in our mind when we started our drafts. It may be better t= o have one thing at a time. =A0 OTOH, even with the current 1:1 protection, I see a more fundamental issue = with the following type of topology, where two primary PEs (i.e. their path= s) share the same penultimate hop router, and the paths to their backup PEs= share the same downstream link from the penultimate hop router.=20 [[Chen,Huaimo]] Your assumption seems not true. Thus your conclusion is not= valid. We may have two primary PEs sharing the same penultimate hop node. = However, when we compute backup paths to their backup PEs, we will avoid th= e situation that the paths to their backup PEs share the same downstream li= nk from the penultimate hop node. =A0 Please see an example below. Assume a CE is dual-homed to PE-prim-1 and PE-= back-1, and another CE is dual-homed to PE-prim-2 and PE-back-2 (not shown = in the picture). If PE-prim-1 fails, P1 will turn on traffic towards P2, ho= ping the traffic to reach PE-back-1. However, not only PE-back-1 will recei= ve the traffic, but also PE-back-2 as well. This is because the path P1 -> = P2 -> PE-back-2 shares the=A0 link P1-P2 with the path P1 -> P2 ->PE-back-1= . Hence, the CE connected to PE-prim-2 and PE-back-2 will receive duplicate= traffic from both PEs at the same time. I think the draft needs to address= this kind problem. =A0 =A0 PE-in ---------- P1 ---------- PE-prim-1 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | \---------- PE-prim-2 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 P2 ---------- PE-back-1 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \---------- PE-back-= 2 =A0 Thanks, =A0 -Yimin Shen Juniper Networks =A0 =A0 =A0 =A0 From kireeti@juniper.net Thu Apr 12 12:48:02 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EF221F86C3 for ; Thu, 12 Apr 2012 12:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrV3DamrgxGB for ; Thu, 12 Apr 2012 12:48:01 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 5200C21F861A for ; Thu, 12 Apr 2012 12:48:01 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT4cxcBImGgO++N0wU9lyyDO10H8kzoGc@postini.com; Thu, 12 Apr 2012 12:48:01 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 12 Apr 2012 12:47:45 -0700 From: Kireeti Kompella To: "mpls@ietf.org" Date: Thu, 12 Apr 2012 12:47:44 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfA== Message-ID: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:48:02 -0000 Hi All, Following up on the presentation at IETF 83, I promised to "take this to th= e list". The two questions are: 1) should we make the ELI a "well-known" reserved label? 2) should we associate the EL with tunnel labels or with application labels= ? This email is to poll the list about (1). Making the ELI a reserved label has the following benefits: a) Transit LSRs can hash on labels up to the ELI and one more (the EL), rat= her than processing all labels in the label stack. b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means o= f bailing out early from grabbing "deeper" fields (e.g., IP headers within = Ethernet within ...) for hashing. c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid ad= ding another entropy-label for the RSVP tunnel *if* the transit LSR finds a= reserved ELI already in the stack. Call this a 'short circuit' rule. d) The short circuit rule can also be used for Carrier of Carrier VPNs and = other situations with label hierarchy. e) A reserved ELI obviates the need for upstream ELI allocation for mLDP an= d P2MP RSVP-TE. (Thanks to Shane for providing some of the above.) The main drawback is the scarcity of reserved labels, which hopefully is ad= dressed by the pixie label draft. So, the question is: should we make the ELI a reserved label? (If no, a sh= ort reason would be helpful.) Kireeti. From kireeti@juniper.net Thu Apr 12 13:22:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C078A21F869D for ; Thu, 12 Apr 2012 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpeRWPeMGVeC for ; Thu, 12 Apr 2012 13:22:52 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9453121F8699 for ; Thu, 12 Apr 2012 13:22:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT4c5mbjjWxvLf2l+BdOaIwF+N/mxcCD6@postini.com; Thu, 12 Apr 2012 13:22:52 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 12 Apr 2012 13:20:41 -0700 From: Kireeti Kompella To: "mpls@ietf.org" Date: Thu, 12 Apr 2012 13:20:40 -0700 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pg== Message-ID: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:22:54 -0000 This email is about: 2) should we associate the EL with tunnel labels or wi= th application labels? NOTE: this is for all applications OTHER THAN LDP pseudowires, where we alr= eady have a solution. The philosophy here is that entropy labels are for improved ECMP; tunnels h= ave ECMP; apps are point-to-point-ish. Here's how it would work: an egress LSR signals, along with a tunnel (LDP o= r RSVP), its ability to process entropy labels. An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tunnel = whose egress can process entropy labels, either decides not to insert entro= py labels, or: 1. X hashes on the incoming packet, using its knowledge of the application. 2. X uses the result of the hash to choose the outgoing tunnel label TL 3. X makes an entropy label from the hash. 4. X pushes the following label stack: Here are the benefits of associating the entropy label with tunnels: a) there are far fewer tunneling protocols than applications. Standardizin= g, implementing, testing, and interop-ing entropy labels just for tunnels r= ather than for all apps (and doing it again in the future for new apps) is = a huge win. b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for spec= ific ingress-egress pairs), the ingress can meaningfully put/not put ELs in= the packet, based on the tunnel rather than the application. c) app label processing on the egress is unaffected. The label stack that = the egress would get (assuming PHP) is . Preprocessing pops E= LI+EL, leaving the processing of the AL the same as before. Processing (if the entropy label is associated with the application) would mean = touching the application label processing microcode for each app, some of w= hich (like VPLS) is fairly complex. d) the "app" of carrying IP over MPLS is no longer a special case. [contex= t: for IP over MPLS, as there is no app label, the label stack has to be , not .] e) if multiple providers are involved in providing a service (CoC VPNs, hie= rarchical tunnels, etc.), then each provider can autonomously insert an ent= ropy label for their tunnel. The downside is that the label stack has one more label because the ELI wou= ld be mandatory: rather than . So, the question: should we associate ELs with tunnels rather than with app= lications (apart from PWs)? (if no, a short reason why would be helpful.) Thanks, Kireeti. From jdrake@juniper.net Thu Apr 12 13:33:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8D21F8707 for ; Thu, 12 Apr 2012 13:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.591 X-Spam-Level: X-Spam-Status: No, score=-6.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwmok4gqZQoM for ; Thu, 12 Apr 2012 13:33:27 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 81C5421F86D9 for ; Thu, 12 Apr 2012 13:33:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT4c8FkfJgscjgxKmVtFai2IiT2Q3KKmk@postini.com; Thu, 12 Apr 2012 13:33:26 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 12 Apr 2012 13:32:35 -0700 From: John E Drake To: Kireeti Kompella , "mpls@ietf.org" Date: Thu, 12 Apr 2012 13:32:34 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAA6wMQ Message-ID: <5E893DB832F57341992548CDBB333163A56E08E2A4@EMBX01-HQ.jnpr.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 20:33:28 -0000 Yes. This is an IQ test and we want to pass it. Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Kireeti Kompella > Sent: Thursday, April 12, 2012 12:48 PM > To: mpls@ietf.org > Subject: [mpls] entropy label draft: reserved label for ELI >=20 > Hi All, >=20 > Following up on the presentation at IETF 83, I promised to "take this > to the list". >=20 > The two questions are: > 1) should we make the ELI a "well-known" reserved label? > 2) should we associate the EL with tunnel labels or with application > labels? >=20 > This email is to poll the list about (1). >=20 > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the EL), > rather than processing all labels in the label stack. >=20 > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a > means of bailing out early from grabbing "deeper" fields (e.g., IP > headers within Ethernet within ...) for hashing. >=20 > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can > avoid adding another entropy-label for the RSVP tunnel *if* the transit > LSR finds a reserved ELI already in the stack. Call this a 'short > circuit' rule. >=20 > d) The short circuit rule can also be used for Carrier of Carrier VPNs > and other situations with label hierarchy. >=20 > e) A reserved ELI obviates the need for upstream ELI allocation for > mLDP and P2MP RSVP-TE. >=20 > (Thanks to Shane for providing some of the above.) >=20 > The main drawback is the scarcity of reserved labels, which hopefully > is addressed by the pixie label draft. >=20 > So, the question is: should we make the ELI a reserved label? (If no, > a short reason would be helpful.) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Thu Apr 12 14:07:50 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0921F8717 for ; Thu, 12 Apr 2012 14:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hp6O-OD9Dl9z for ; Thu, 12 Apr 2012 14:07:49 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4776921F86EF for ; Thu, 12 Apr 2012 14:07:49 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKT4dEJPMvhgdsOMPf750jpjlgF4Ic8APW@postini.com; Thu, 12 Apr 2012 14:07:49 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 12 Apr 2012 14:07:45 -0700 From: John E Drake To: Kireeti Kompella , "mpls@ietf.org" Date: Thu, 12 Apr 2012 14:07:44 -0700 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgABoCNA Message-ID: <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> In-Reply-To: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:07:50 -0000 Yes, although I think the term 'associating the EL with tunnel labels' and = its variants are terrible. What we a really saying is that the ability to process entropy labels is a = nodal capability that is indicated in the signaling of tunnels to that node= . =20 We are also saying that the application is still responsible for creating t= he entropy label and for placing it in the MPLS label stack. All we are do= ing is specifying a different order in which the application places labels = in the stack. =20 I think the most compelling reasons for specifying this order is that it ma= kes the egress node processing uniform and amenable to hardware implementat= ion, and that it ensures that the applications on the egress node are bliss= fully unaware of entropy labels. Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Kireeti Kompella > Sent: Thursday, April 12, 2012 1:21 PM > To: mpls@ietf.org > Subject: [mpls] entropy labels: associate with tunnels or apps? >=20 > This email is about: 2) should we associate the EL with tunnel labels > or with application labels? >=20 > NOTE: this is for all applications OTHER THAN LDP pseudowires, where we > already have a solution. >=20 > The philosophy here is that entropy labels are for improved ECMP; > tunnels have ECMP; apps are point-to-point-ish. >=20 > Here's how it would work: an egress LSR signals, along with a tunnel > (LDP or RSVP), its ability to process entropy labels. > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a > tunnel whose egress can process entropy labels, either decides not to > insert entropy labels, or: > 1. X hashes on the incoming packet, using its knowledge of the > application. > 2. X uses the result of the hash to choose the outgoing tunnel label TL > 3. X makes an entropy label from the hash. > 4. X pushes the following label stack: >=20 > Here are the benefits of associating the entropy label with tunnels: > a) there are far fewer tunneling protocols than applications. > Standardizing, implementing, testing, and interop-ing entropy labels > just for tunnels rather than for all apps (and doing it again in the > future for new apps) is a huge win. >=20 > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for > specific ingress-egress pairs), the ingress can meaningfully put/not > put ELs in the packet, based on the tunnel rather than the application. >=20 > c) app label processing on the egress is unaffected. The label stack > that the egress would get (assuming PHP) is . > Preprocessing pops ELI+EL, leaving the processing of the AL the same as > before. Processing (if the entropy label is associated with > the application) would mean touching the application label processing > microcode for each app, some of which (like VPLS) is fairly complex. >=20 > d) the "app" of carrying IP over MPLS is no longer a special case. > [context: for IP over MPLS, as there is no app label, the label stack > has to be , not .] >=20 > e) if multiple providers are involved in providing a service (CoC VPNs, > hierarchical tunnels, etc.), then each provider can autonomously insert > an entropy label for their tunnel. >=20 > The downside is that the label stack has one more label because the ELI > would be mandatory: rather than . >=20 > So, the question: should we associate ELs with tunnels rather than with > applications (apart from PWs)? (if no, a short reason why would be > helpful.) >=20 > Thanks, > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Thu Apr 12 14:14:46 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D4D21F8762 for ; Thu, 12 Apr 2012 14:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjndUw9yiSun for ; Thu, 12 Apr 2012 14:14:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3236121F8760 for ; Thu, 12 Apr 2012 14:14:46 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3CLEQGH028774; Thu, 12 Apr 2012 16:14:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 12 Apr 2012 17:14:33 -0400 From: Jeff Tantsura To: Kireeti Kompella , "mpls@ietf.org" Date: Thu, 12 Apr 2012 17:14:32 -0400 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAC3hJQ Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF619134BC290@EUSAACMS0701.eamcs.ericsson.se> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:14:47 -0000 Hi Kireeti, For all the reasons mentioned below (and hence consequences for the FW perf= ormance ) I think we should be making ELI a "well-known" reserved label. Regards, Jeff -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Thursday, April 12, 2012 12:48 PM To: mpls@ietf.org Subject: [mpls] entropy label draft: reserved label for ELI Hi All, Following up on the presentation at IETF 83, I promised to "take this to th= e list". The two questions are: 1) should we make the ELI a "well-known" reserved label? 2) should we associate the EL with tunnel labels or with application labels= ? This email is to poll the list about (1). Making the ELI a reserved label has the following benefits: a) Transit LSRs can hash on labels up to the ELI and one more (the EL), rat= her than processing all labels in the label stack. b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means o= f bailing out early from grabbing "deeper" fields (e.g., IP headers within = Ethernet within ...) for hashing. c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid ad= ding another entropy-label for the RSVP tunnel *if* the transit LSR finds a= reserved ELI already in the stack. Call this a 'short circuit' rule. d) The short circuit rule can also be used for Carrier of Carrier VPNs and = other situations with label hierarchy. e) A reserved ELI obviates the need for upstream ELI allocation for mLDP an= d P2MP RSVP-TE. (Thanks to Shane for providing some of the above.) The main drawback is the scarcity of reserved labels, which hopefully is ad= dressed by the pixie label draft. So, the question is: should we make the ELI a reserved label? (If no, a sh= ort reason would be helpful.) Kireeti. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Thu Apr 12 14:19:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406EE21F8770 for ; Thu, 12 Apr 2012 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVxWHxNQUGuR for ; Thu, 12 Apr 2012 14:19:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 761DF21F8722 for ; Thu, 12 Apr 2012 14:19:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3CLIU8G029638; Thu, 12 Apr 2012 16:19:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 12 Apr 2012 17:18:56 -0400 From: Jeff Tantsura To: Kireeti Kompella , "mpls@ietf.org" Date: Thu, 12 Apr 2012 17:18:55 -0400 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgAB7MKA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF619134BC29C@EUSAACMS0701.eamcs.ericsson.se> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> In-Reply-To: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 21:19:03 -0000 Hi Kireeti, IMO EL should be application agnostic as hash result for most application w= ould be exactly the same (flow) - 5 tuple based for IPv4 or IPv6 or MAC for= non IP.=20 Regards, Jeff -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Thursday, April 12, 2012 1:21 PM To: mpls@ietf.org Subject: [mpls] entropy labels: associate with tunnels or apps? This email is about: 2) should we associate the EL with tunnel labels or wi= th application labels? NOTE: this is for all applications OTHER THAN LDP pseudowires, where we alr= eady have a solution. The philosophy here is that entropy labels are for improved ECMP; tunnels h= ave ECMP; apps are point-to-point-ish. Here's how it would work: an egress LSR signals, along with a tunnel (LDP o= r RSVP), its ability to process entropy labels. An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tunnel = whose egress can process entropy labels, either decides not to insert entro= py labels, or: 1. X hashes on the incoming packet, using its knowledge of the application. 2. X uses the result of the hash to choose the outgoing tunnel label TL 3. = X makes an entropy label from the hash. 4. X pushes the following label stack: Here are the benefits of associating the entropy label with tunnels: a) there are far fewer tunneling protocols than applications. Standardizin= g, implementing, testing, and interop-ing entropy labels just for tunnels r= ather than for all apps (and doing it again in the future for new apps) is = a huge win. b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for spec= ific ingress-egress pairs), the ingress can meaningfully put/not put ELs in= the packet, based on the tunnel rather than the application. c) app label processing on the egress is unaffected. The label stack that = the egress would get (assuming PHP) is . Preprocessing pops E= LI+EL, leaving the processing of the AL the same as before. Processing (if the entropy label is associated with the application) would mean = touching the application label processing microcode for each app, some of w= hich (like VPLS) is fairly complex. d) the "app" of carrying IP over MPLS is no longer a special case. [contex= t: for IP over MPLS, as there is no app label, the label stack has to be , not .] e) if multiple providers are involved in providing a service (CoC VPNs, hie= rarchical tunnels, etc.), then each provider can autonomously insert an ent= ropy label for their tunnel. The downside is that the label stack has one more label because the ELI wou= ld be mandatory: rather than . So, the question: should we associate ELs with tunnels rather than with app= lications (apart from PWs)? (if no, a short reason why would be helpful.) Thanks, Kireeti. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Thu Apr 12 17:52:31 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3827A21F84FA for ; Thu, 12 Apr 2012 17:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLqdi4poVRN5 for ; Thu, 12 Apr 2012 17:52:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2730921F8557 for ; Thu, 12 Apr 2012 17:52:30 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3D0qQQ6019986; Thu, 12 Apr 2012 19:52:27 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 12 Apr 2012 20:52:27 -0400 From: Gregory Mirsky To: John E Drake , Kireeti Kompella , "mpls@ietf.org" Date: Thu, 12 Apr 2012 20:52:26 -0400 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgABoCNAAABNGFA= Message-ID: References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 00:52:31 -0000 Hi John, this is not to answer Kireeti's question. I think that, strictly speaking, scope of "the ability to process entropy l= abels" depends on label allocation mode. For per-interface it is an interfa= ce's capability.=20 Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Joh= n E Drake Sent: Thursday, April 12, 2012 2:08 PM To: Kireeti Kompella; mpls@ietf.org Subject: Re: [mpls] entropy labels: associate with tunnels or apps? Yes, although I think the term 'associating the EL with tunnel labels' and = its variants are terrible. What we a really saying is that the ability to process entropy labels is a = nodal capability that is indicated in the signaling of tunnels to that node= . =20 We are also saying that the application is still responsible for creating t= he entropy label and for placing it in the MPLS label stack. All we are do= ing is specifying a different order in which the application places labels = in the stack. =20 I think the most compelling reasons for specifying this order is that it ma= kes the egress node processing uniform and amenable to hardware implementat= ion, and that it ensures that the applications on the egress node are bliss= fully unaware of entropy labels. Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Kireeti Kompella > Sent: Thursday, April 12, 2012 1:21 PM > To: mpls@ietf.org > Subject: [mpls] entropy labels: associate with tunnels or apps? >=20 > This email is about: 2) should we associate the EL with tunnel labels=20 > or with application labels? >=20 > NOTE: this is for all applications OTHER THAN LDP pseudowires, where=20 > we already have a solution. >=20 > The philosophy here is that entropy labels are for improved ECMP;=20 > tunnels have ECMP; apps are point-to-point-ish. >=20 > Here's how it would work: an egress LSR signals, along with a tunnel=20 > (LDP or RSVP), its ability to process entropy labels. > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a=20 > tunnel whose egress can process entropy labels, either decides not to=20 > insert entropy labels, or: > 1. X hashes on the incoming packet, using its knowledge of the=20 > application. > 2. X uses the result of the hash to choose the outgoing tunnel label=20 > TL 3. X makes an entropy label from the hash. > 4. X pushes the following label stack: >=20 > Here are the benefits of associating the entropy label with tunnels: > a) there are far fewer tunneling protocols than applications. > Standardizing, implementing, testing, and interop-ing entropy labels=20 > just for tunnels rather than for all apps (and doing it again in the=20 > future for new apps) is a huge win. >=20 > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for=20 > specific ingress-egress pairs), the ingress can meaningfully put/not=20 > put ELs in the packet, based on the tunnel rather than the application. >=20 > c) app label processing on the egress is unaffected. The label stack=20 > that the egress would get (assuming PHP) is . > Preprocessing pops ELI+EL, leaving the processing of the AL the same=20 > as before. Processing (if the entropy label is associated=20 > with the application) would mean touching the application label=20 > processing microcode for each app, some of which (like VPLS) is fairly co= mplex. >=20 > d) the "app" of carrying IP over MPLS is no longer a special case. > [context: for IP over MPLS, as there is no app label, the label stack=20 > has to be , not .] >=20 > e) if multiple providers are involved in providing a service (CoC=20 > VPNs, hierarchical tunnels, etc.), then each provider can autonomously=20 > insert an entropy label for their tunnel. >=20 > The downside is that the label stack has one more label because the=20 > ELI would be mandatory: rather than . >=20 > So, the question: should we associate ELs with tunnels rather than=20 > with applications (apart from PWs)? (if no, a short reason why would=20 > be > helpful.) >=20 > Thanks, > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Thu Apr 12 18:01:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8DB21F84FB for ; Thu, 12 Apr 2012 18:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdRsrmvQYn5v for ; Thu, 12 Apr 2012 18:01:50 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4B21F84CD for ; Thu, 12 Apr 2012 18:01:49 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 12 Apr 2012 18:11:23 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.131]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 12 Apr 2012 18:01:39 -0700 From: "Shahram Davari" To: "Kireeti Kompella" , "mpls@ietf.org" Date: Thu, 12 Apr 2012 18:01:36 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAKrnUg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB9828@SJEXCHCCR02.corp.ad.broadcom.com> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6399A2B13E017184378-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 01:01:51 -0000 Hi Kireeti, What is the relationship between this EL and the fat Label (RFC6391)? Can t= hey both coexist? How many Entropy Labels can exist in a stack? How many EL= I can exist in a stack? Thanks Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Thursday, April 12, 2012 12:48 PM To: mpls@ietf.org Subject: [mpls] entropy label draft: reserved label for ELI Hi All, Following up on the presentation at IETF 83, I promised to "take this to th= e list". The two questions are: 1) should we make the ELI a "well-known" reserved label? 2) should we associate the EL with tunnel labels or with application labels= ? This email is to poll the list about (1). Making the ELI a reserved label has the following benefits: a) Transit LSRs can hash on labels up to the ELI and one more (the EL), rat= her than processing all labels in the label stack. b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means o= f bailing out early from grabbing "deeper" fields (e.g., IP headers within = Ethernet within ...) for hashing. c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid ad= ding another entropy-label for the RSVP tunnel *if* the transit LSR finds a= reserved ELI already in the stack. Call this a 'short circuit' rule. d) The short circuit rule can also be used for Carrier of Carrier VPNs and = other situations with label hierarchy. e) A reserved ELI obviates the need for upstream ELI allocation for mLDP an= d P2MP RSVP-TE. (Thanks to Shane for providing some of the above.) The main drawback is the scarcity of reserved labels, which hopefully is ad= dressed by the pixie label draft. So, the question is: should we make the ELI a reserved label? (If no, a sh= ort reason would be helpful.) Kireeti. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Fri Apr 13 01:00:06 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8D721F86FC; Fri, 13 Apr 2012 01:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDD5SrsskT+6; Fri, 13 Apr 2012 01:00:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F6621F8694; Fri, 13 Apr 2012 01:00:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413080006.22207.48170.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 01:00:06 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:00:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : MPLS-TP Traffic Engineering (TE) Management Information = Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-03.txt Pages : 47 Date : 2012-04-13 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-te-mib-03.txt From jdrake@juniper.net Fri Apr 13 04:15:59 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961421F87BC for ; Fri, 13 Apr 2012 04:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NSa2g8IfpXM for ; Fri, 13 Apr 2012 04:15:58 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2F69421F8778 for ; Fri, 13 Apr 2012 04:15:58 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT4gK6jQTU9bFY5DicUchV3SFXZVfjmeD@postini.com; Fri, 13 Apr 2012 04:15:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Apr 2012 04:15:47 -0700 From: John E Drake To: Gregory Mirsky , Kireeti Kompella , "mpls@ietf.org" Date: Fri, 13 Apr 2012 04:15:46 -0700 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgABoCNAAABNGFAAHUb5QA== Message-ID: <5E893DB832F57341992548CDBB333163A56E1F8C15@EMBX01-HQ.jnpr.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 11:15:59 -0000 Greg, Why do you make that coupling? It's not obvious to me that the label alloc= ation mode has anything to do with the ability to recognize and discard ELI= /EL label pairs. Thanks, John Sent from my iPhone > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, April 12, 2012 5:52 PM > To: John E Drake; Kireeti Kompella; mpls@ietf.org > Subject: RE: entropy labels: associate with tunnels or apps? >=20 > Hi John, > this is not to answer Kireeti's question. > I think that, strictly speaking, scope of "the ability to process > entropy labels" depends on label allocation mode. For per-interface it > is an interface's capability. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > John E Drake > Sent: Thursday, April 12, 2012 2:08 PM > To: Kireeti Kompella; mpls@ietf.org > Subject: Re: [mpls] entropy labels: associate with tunnels or apps? >=20 > Yes, although I think the term 'associating the EL with tunnel labels' > and its variants are terrible. >=20 > What we a really saying is that the ability to process entropy labels > is a nodal capability that is indicated in the signaling of tunnels to > that node. >=20 > We are also saying that the application is still responsible for > creating the entropy label and for placing it in the MPLS label stack. > All we are doing is specifying a different order in which the > application places labels in the stack. >=20 > I think the most compelling reasons for specifying this order is that > it makes the egress node processing uniform and amenable to hardware > implementation, and that it ensures that the applications on the egress > node are blissfully unaware of entropy labels. >=20 > Sent from my iPhone >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Kireeti Kompella > > Sent: Thursday, April 12, 2012 1:21 PM > > To: mpls@ietf.org > > Subject: [mpls] entropy labels: associate with tunnels or apps? > > > > This email is about: 2) should we associate the EL with tunnel labels > > or with application labels? > > > > NOTE: this is for all applications OTHER THAN LDP pseudowires, where > > we already have a solution. > > > > The philosophy here is that entropy labels are for improved ECMP; > > tunnels have ECMP; apps are point-to-point-ish. > > > > Here's how it would work: an egress LSR signals, along with a tunnel > > (LDP or RSVP), its ability to process entropy labels. > > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a > > tunnel whose egress can process entropy labels, either decides not to > > insert entropy labels, or: > > 1. X hashes on the incoming packet, using its knowledge of the > > application. > > 2. X uses the result of the hash to choose the outgoing tunnel label > > TL 3. X makes an entropy label from the hash. > > 4. X pushes the following label stack: > > > > Here are the benefits of associating the entropy label with tunnels: > > a) there are far fewer tunneling protocols than applications. > > Standardizing, implementing, testing, and interop-ing entropy labels > > just for tunnels rather than for all apps (and doing it again in the > > future for new apps) is a huge win. > > > > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE > for > > specific ingress-egress pairs), the ingress can meaningfully put/not > > put ELs in the packet, based on the tunnel rather than the > application. > > > > c) app label processing on the egress is unaffected. The label stack > > that the egress would get (assuming PHP) is . > > Preprocessing pops ELI+EL, leaving the processing of the AL the same > > as before. Processing (if the entropy label is associated > > with the application) would mean touching the application label > > processing microcode for each app, some of which (like VPLS) is > fairly complex. > > > > d) the "app" of carrying IP over MPLS is no longer a special case. > > [context: for IP over MPLS, as there is no app label, the label stack > > has to be , not .] > > > > e) if multiple providers are involved in providing a service (CoC > > VPNs, hierarchical tunnels, etc.), then each provider can > autonomously > > insert an entropy label for their tunnel. > > > > The downside is that the label stack has one more label because the > > ELI would be mandatory: rather than . > > > > So, the question: should we associate ELs with tunnels rather than > > with applications (apart from PWs)? (if no, a short reason why would > > be > > helpful.) > > > > Thanks, > > Kireeti. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From prvs=9450bd28b1=hshah@ciena.com Fri Apr 13 06:26:57 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A231321F8625 for ; Fri, 13 Apr 2012 06:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFINHMyhZNWM for ; Fri, 13 Apr 2012 06:26:57 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1367B21F8584 for ; Fri, 13 Apr 2012 06:26:56 -0700 (PDT) Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q3DDOgmW020579; Fri, 13 Apr 2012 09:26:56 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0b-00103a01.pphosted.com with ESMTP id 146j240ehe-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Apr 2012 09:26:55 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Fri, 13 Apr 2012 09:26:55 -0400 From: "Shah, Himanshu" To: Kireeti Kompella , "mpls@ietf.org" Date: Fri, 13 Apr 2012 09:26:53 -0400 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAkbDwg Message-ID: References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18834.007 x-tm-as-result: No--47.532700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498, 1.0.260, 0.0.0000 definitions=2012-04-13_05:2012-04-13, 2012-04-13, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1204130109 Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 13:26:57 -0000 My Opinion on your poll - 1) Yes - Make ELI a reserved label 2) EL with application label would be my preference (some of your (a) to (e= ) points below=20 seems to favor that option, in my view) and would address runaway stack = depth increase concerns. /himanshu -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Thursday, April 12, 2012 3:48 PM To: mpls@ietf.org Subject: [mpls] entropy label draft: reserved label for ELI Hi All, Following up on the presentation at IETF 83, I promised to "take this to th= e list". The two questions are: 1) should we make the ELI a "well-known" reserved label? 2) should we associate the EL with tunnel labels or with application labels= ? This email is to poll the list about (1). Making the ELI a reserved label has the following benefits: a) Transit LSRs can hash on labels up to the ELI and one more (the EL), rat= her than processing all labels in the label stack. b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means o= f bailing out early from grabbing "deeper" fields (e.g., IP headers within = Ethernet within ...) for hashing. c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid ad= ding another entropy-label for the RSVP tunnel *if* the transit LSR finds a= reserved ELI already in the stack. Call this a 'short circuit' rule. d) The short circuit rule can also be used for Carrier of Carrier VPNs and = other situations with label hierarchy. e) A reserved ELI obviates the need for upstream ELI allocation for mLDP an= d P2MP RSVP-TE. (Thanks to Shane for providing some of the above.) The main drawback is the scarcity of reserved labels, which hopefully is ad= dressed by the pixie label draft. So, the question is: should we make the ELI a reserved label? (If no, a sh= ort reason would be helpful.) Kireeti. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Fri Apr 13 06:30:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D2721F86E8; Fri, 13 Apr 2012 06:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8odLfo-nX86J; Fri, 13 Apr 2012 06:30:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A837021F86D8; Fri, 13 Apr 2012 06:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413133023.1830.23086.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 06:30:23 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 13:30:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Configuration of Pro-Active Operations, Administration, = and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP= Ping Author(s) : Elisa Bellagamba Loa Andersson Pontus Skoldstrom Dave Ward John Drake Filename : draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-04.txt Pages : 22 Date : 2012-04-13 This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that are carried by the LSP Ping protocol This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-co= nf-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-mpls-tp-oam-con= f-04.txt From kireeti@juniper.net Fri Apr 13 08:53:15 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E2E21F872A for ; Fri, 13 Apr 2012 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Tac1USvuiI for ; Fri, 13 Apr 2012 08:53:15 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id C55F121F8701 for ; Fri, 13 Apr 2012 08:53:13 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT4hL6QpqUZihLbXkxiIKvXevvv1Rm2Zn@postini.com; Fri, 13 Apr 2012 08:53:14 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Apr 2012 08:52:44 -0700 From: Kireeti Kompella To: "Shah, Himanshu" Date: Fri, 13 Apr 2012 08:52:45 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0ZjXdJwtZZkxqCTga6VjMrq/Ivlw== Message-ID: <37F377D9-29FF-41C4-9918-D3B399A9EF7C@juniper.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:53:15 -0000 Himanshu, On Apr 13, 2012, at 6:27, "Shah, Himanshu" wrote: > My Opinion on your poll - >=20 > 1) Yes - Make ELI a reserved label > 2) EL with application label would be my preference (some of your (a) to = (e) points below=20 > seems to favor that option, in my view) and would address runaway stack= depth increase concerns. Thanks for your replies. The points a-e were for a reserved ELI, not for (2), for which you should s= ee my other mail. I fully understand your comment about "runaway stack depth", and am very so= rry that it's a problem for you. Of course, not doing entropy labels at al= l is always an option, and that saves yet another label. Kireeti > /himanshu >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of K= ireeti Kompella > Sent: Thursday, April 12, 2012 3:48 PM > To: mpls@ietf.org > Subject: [mpls] entropy label draft: reserved label for ELI >=20 > Hi All, >=20 > Following up on the presentation at IETF 83, I promised to "take this to = the list". >=20 > The two questions are: > 1) should we make the ELI a "well-known" reserved label? > 2) should we associate the EL with tunnel labels or with application labe= ls? >=20 > This email is to poll the list about (1). >=20 > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the EL), r= ather than processing all labels in the label stack. >=20 > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means= of bailing out early from grabbing "deeper" fields (e.g., IP headers withi= n Ethernet within ...) for hashing. >=20 > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid = adding another entropy-label for the RSVP tunnel *if* the transit LSR finds= a reserved ELI already in the stack. Call this a 'short circuit' rule. >=20 > d) The short circuit rule can also be used for Carrier of Carrier VPNs an= d other situations with label hierarchy. >=20 > e) A reserved ELI obviates the need for upstream ELI allocation for mLDP = and P2MP RSVP-TE. >=20 > (Thanks to Shane for providing some of the above.) >=20 > The main drawback is the scarcity of reserved labels, which hopefully is = addressed by the pixie label draft. >=20 > So, the question is: should we make the ELI a reserved label? (If no, a = short reason would be helpful.) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Fri Apr 13 10:26:03 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FD111E8080; Fri, 13 Apr 2012 10:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eng4fx62I1Y9; Fri, 13 Apr 2012 10:26:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA8521F87A5; Fri, 13 Apr 2012 10:26:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120413172602.24055.82175.idtracker@ietfa.amsl.com> Date: Fri, 13 Apr 2012 10:26:02 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mib-management-overview-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 17:26:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Multiprotocol Label Switching Transport Profile (MPLS-TP= ) MIB-based Management Overview Author(s) : Daniel King Venkatesan Mahalingam Filename : draft-ietf-mpls-tp-mib-management-overview-08.txt Pages : 26 Date : 2012-04-13 A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overv= iew-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-mib-management-overvi= ew-08.txt From gregory.mirsky@ericsson.com Fri Apr 13 11:52:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDD621F8448 for ; Fri, 13 Apr 2012 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwHch-61LcPL for ; Fri, 13 Apr 2012 11:52:18 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0482521F8557 for ; Fri, 13 Apr 2012 11:52:16 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3DIq8Mg032484; Fri, 13 Apr 2012 13:52:15 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.170]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 13 Apr 2012 14:52:13 -0400 From: Gregory Mirsky To: John E Drake , Kireeti Kompella , "mpls@ietf.org" Date: Fri, 13 Apr 2012 14:52:11 -0400 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgABoCNAAABNGFAAHUb5QAAPzM/Q Message-ID: References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A56E1F8C15@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56E1F8C15@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 18:52:24 -0000 Hi John, I think that "nodal capability" is too strong requirement in case of per-in= terface label allocation. I think that in case of per-interface label alloc= ation interpretation of capability to process ELI/EL labels can be limited = to scope of that interface. Regards, Greg -----Original Message----- From: John E Drake [mailto:jdrake@juniper.net]=20 Sent: Friday, April 13, 2012 4:16 AM To: Gregory Mirsky; Kireeti Kompella; mpls@ietf.org Subject: RE: entropy labels: associate with tunnels or apps? Greg, Why do you make that coupling? It's not obvious to me that the label alloc= ation mode has anything to do with the ability to recognize and discard ELI= /EL label pairs. Thanks, John Sent from my iPhone > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Thursday, April 12, 2012 5:52 PM > To: John E Drake; Kireeti Kompella; mpls@ietf.org > Subject: RE: entropy labels: associate with tunnels or apps? >=20 > Hi John, > this is not to answer Kireeti's question. > I think that, strictly speaking, scope of "the ability to process=20 > entropy labels" depends on label allocation mode. For per-interface it=20 > is an interface's capability. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of John E Drake > Sent: Thursday, April 12, 2012 2:08 PM > To: Kireeti Kompella; mpls@ietf.org > Subject: Re: [mpls] entropy labels: associate with tunnels or apps? >=20 > Yes, although I think the term 'associating the EL with tunnel labels' > and its variants are terrible. >=20 > What we a really saying is that the ability to process entropy labels=20 > is a nodal capability that is indicated in the signaling of tunnels to=20 > that node. >=20 > We are also saying that the application is still responsible for=20 > creating the entropy label and for placing it in the MPLS label stack. > All we are doing is specifying a different order in which the=20 > application places labels in the stack. >=20 > I think the most compelling reasons for specifying this order is that=20 > it makes the egress node processing uniform and amenable to hardware=20 > implementation, and that it ensures that the applications on the=20 > egress node are blissfully unaware of entropy labels. >=20 > Sent from my iPhone >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > > Of Kireeti Kompella > > Sent: Thursday, April 12, 2012 1:21 PM > > To: mpls@ietf.org > > Subject: [mpls] entropy labels: associate with tunnels or apps? > > > > This email is about: 2) should we associate the EL with tunnel=20 > > labels or with application labels? > > > > NOTE: this is for all applications OTHER THAN LDP pseudowires, where=20 > > we already have a solution. > > > > The philosophy here is that entropy labels are for improved ECMP;=20 > > tunnels have ECMP; apps are point-to-point-ish. > > > > Here's how it would work: an egress LSR signals, along with a tunnel=20 > > (LDP or RSVP), its ability to process entropy labels. > > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a=20 > > tunnel whose egress can process entropy labels, either decides not=20 > > to insert entropy labels, or: > > 1. X hashes on the incoming packet, using its knowledge of the=20 > > application. > > 2. X uses the result of the hash to choose the outgoing tunnel label=20 > > TL 3. X makes an entropy label from the hash. > > 4. X pushes the following label stack: > > > > Here are the benefits of associating the entropy label with tunnels: > > a) there are far fewer tunneling protocols than applications. > > Standardizing, implementing, testing, and interop-ing entropy labels=20 > > just for tunnels rather than for all apps (and doing it again in the=20 > > future for new apps) is a huge win. > > > > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE > for > > specific ingress-egress pairs), the ingress can meaningfully put/not=20 > > put ELs in the packet, based on the tunnel rather than the > application. > > > > c) app label processing on the egress is unaffected. The label=20 > > stack that the egress would get (assuming PHP) is . > > Preprocessing pops ELI+EL, leaving the processing of the AL the same=20 > > as before. Processing (if the entropy label is associated=20 > > with the application) would mean touching the application label=20 > > processing microcode for each app, some of which (like VPLS) is > fairly complex. > > > > d) the "app" of carrying IP over MPLS is no longer a special case. > > [context: for IP over MPLS, as there is no app label, the label=20 > > stack has to be , not .] > > > > e) if multiple providers are involved in providing a service (CoC=20 > > VPNs, hierarchical tunnels, etc.), then each provider can > autonomously > > insert an entropy label for their tunnel. > > > > The downside is that the label stack has one more label because the=20 > > ELI would be mandatory: rather than . > > > > So, the question: should we associate ELs with tunnels rather than=20 > > with applications (apart from PWs)? (if no, a short reason why=20 > > would be > > helpful.) > > > > Thanks, > > Kireeti. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Fri Apr 13 12:15:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E476921F87A2 for ; Fri, 13 Apr 2012 12:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sXb47TMSQ4p for ; Fri, 13 Apr 2012 12:15:17 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1464421F879D for ; Fri, 13 Apr 2012 12:15:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT4h7RJ+VO8O/4IpaImkhZ5DusXBGkl5e@postini.com; Fri, 13 Apr 2012 12:15:17 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 Apr 2012 12:12:03 -0700 From: Kireeti Kompella To: John E Drake Date: Fri, 13 Apr 2012 12:12:01 -0700 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0ZqU6YJZodDxmERbqmKRgRdTUFgQ== Message-ID: <0BB96957-273F-4F2D-97DA-4DFE503333CE@juniper.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:15:18 -0000 Hi John, On Apr 12, 2012, at 14:07 , John E Drake wrote: > Yes, although I think the term 'associating the EL with tunnel labels' an= d its variants are terrible. You're right. It sets up the wrong mental picture. > What we a really saying is that the ability to process entropy labels is = a nodal capability that is indicated in the signaling of tunnels to that no= de. =20 Right. > We are also saying that the application is still responsible for creating= the entropy label and for placing it in the MPLS label stack. All we are = doing is specifying a different order in which the application places label= s in the stack. =20 Right. > I think the most compelling reasons for specifying this order is that it = makes the egress node processing uniform and amenable to hardware implement= ation, and that it ensures that the applications on the egress node are bli= ssfully unaware of entropy labels. Reason (a) is also pretty compelling, but point taken. Thanks, Kireeti. > Sent from my iPhone >=20 >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Kireeti Kompella >> Sent: Thursday, April 12, 2012 1:21 PM >> To: mpls@ietf.org >> Subject: [mpls] entropy labels: associate with tunnels or apps? >>=20 >> This email is about: 2) should we associate the EL with tunnel labels >> or with application labels? >>=20 >> NOTE: this is for all applications OTHER THAN LDP pseudowires, where we >> already have a solution. >>=20 >> The philosophy here is that entropy labels are for improved ECMP; >> tunnels have ECMP; apps are point-to-point-ish. >>=20 >> Here's how it would work: an egress LSR signals, along with a tunnel >> (LDP or RSVP), its ability to process entropy labels. >> An ingress LSR X, when it resolves an application (e.g. L3VPN) to a >> tunnel whose egress can process entropy labels, either decides not to >> insert entropy labels, or: >> 1. X hashes on the incoming packet, using its knowledge of the >> application. >> 2. X uses the result of the hash to choose the outgoing tunnel label TL >> 3. X makes an entropy label from the hash. >> 4. X pushes the following label stack: >>=20 >> Here are the benefits of associating the entropy label with tunnels: >> a) there are far fewer tunneling protocols than applications. >> Standardizing, implementing, testing, and interop-ing entropy labels >> just for tunnels rather than for all apps (and doing it again in the >> future for new apps) is a huge win. >>=20 >> b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for >> specific ingress-egress pairs), the ingress can meaningfully put/not >> put ELs in the packet, based on the tunnel rather than the application. >>=20 >> c) app label processing on the egress is unaffected. The label stack >> that the egress would get (assuming PHP) is . >> Preprocessing pops ELI+EL, leaving the processing of the AL the same as >> before. Processing (if the entropy label is associated with >> the application) would mean touching the application label processing >> microcode for each app, some of which (like VPLS) is fairly complex. >>=20 >> d) the "app" of carrying IP over MPLS is no longer a special case. >> [context: for IP over MPLS, as there is no app label, the label stack >> has to be , not .] >>=20 >> e) if multiple providers are involved in providing a service (CoC VPNs, >> hierarchical tunnels, etc.), then each provider can autonomously insert >> an entropy label for their tunnel. >>=20 >> The downside is that the label stack has one more label because the ELI >> would be mandatory: rather than . >>=20 >> So, the question: should we associate ELs with tunnels rather than with >> applications (apart from PWs)? (if no, a short reason why would be >> helpful.) >>=20 >> Thanks, >> Kireeti. >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Fri Apr 13 12:17:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF87011E80D6 for ; Fri, 13 Apr 2012 12:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3avvullh8jUe for ; Fri, 13 Apr 2012 12:17:08 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A952411E80D5 for ; Fri, 13 Apr 2012 12:17:07 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT4h7slIPOIw6mgssxMn+vaX6p5na4slB@postini.com; Fri, 13 Apr 2012 12:17:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Apr 2012 12:16:46 -0700 From: Kireeti Kompella To: Shahram Davari Date: Fri, 13 Apr 2012 12:16:46 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Zqfg0nDFuTr5KQqyNLXUyq6a3uw== Message-ID: <18675970-8537-4A1B-8C0D-E9848F70AAE1@juniper.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB9828@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB9828@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:17:09 -0000 Hi Shahram, On Apr 12, 2012, at 18:01 , Shahram Davari wrote: > Hi Kireeti, >=20 > What is the relationship between this EL and the fat Label (RFC6391)? Same thing. > Can they both coexist? How many Entropy Labels can exist in a stack? How = many ELI can exist in a stack? Yes, they can coexist. In theoretical cases, there can be many entropy lab= els; each one, except the fat PW entropy label, must be preceded by an ELI. Practically speaking, there would be just one entropy label, either below t= he PW label (for fat PWs), or below the tunnel label (for all other apps, a= ssuming that's what we agree on). The main case for multiple entropy label= s is inter-provider hierarchical situations. HTH, Kireeti. > Thanks > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of K= ireeti Kompella > Sent: Thursday, April 12, 2012 12:48 PM > To: mpls@ietf.org > Subject: [mpls] entropy label draft: reserved label for ELI >=20 > Hi All, >=20 > Following up on the presentation at IETF 83, I promised to "take this to = the list". >=20 > The two questions are: > 1) should we make the ELI a "well-known" reserved label? > 2) should we associate the EL with tunnel labels or with application labe= ls? >=20 > This email is to poll the list about (1). >=20 > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the EL), r= ather than processing all labels in the label stack. >=20 > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means= of bailing out early from grabbing "deeper" fields (e.g., IP headers withi= n Ethernet within ...) for hashing. >=20 > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid = adding another entropy-label for the RSVP tunnel *if* the transit LSR finds= a reserved ELI already in the stack. Call this a 'short circuit' rule. >=20 > d) The short circuit rule can also be used for Carrier of Carrier VPNs an= d other situations with label hierarchy. >=20 > e) A reserved ELI obviates the need for upstream ELI allocation for mLDP = and P2MP RSVP-TE. >=20 > (Thanks to Shane for providing some of the above.) >=20 > The main drawback is the scarcity of reserved labels, which hopefully is = addressed by the pixie label draft. >=20 > So, the question is: should we make the ELI a reserved label? (If no, a = short reason would be helpful.) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From davari@broadcom.com Fri Apr 13 12:24:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7786811E80E0 for ; Fri, 13 Apr 2012 12:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOmOotl8Ee-q for ; Fri, 13 Apr 2012 12:24:08 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id E325711E809D for ; Fri, 13 Apr 2012 12:24:07 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 13 Apr 2012 12:34:28 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.13) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 13 Apr 2012 12:24:03 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 12:23:42 -0700 From: "Shahram Davari" To: "Kireeti Kompella" Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAKrnUgADUyNQAADn8kYA== Date: Fri, 13 Apr 2012 19:23:41 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F2801F839@SJEXCHMB12.corp.ad.broadcom.com> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB9828@SJEXCHCCR02.corp.ad.broadcom.com> <18675970-8537-4A1B-8C0D-E9848F70AAE1@juniper.net> In-Reply-To: <18675970-8537-4A1B-8C0D-E9848F70AAE1@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.65.99] MIME-Version: 1.0 X-WSS-ID: 6396A0493IO4543277-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:24:08 -0000 Thanks Kireeti, One more question. Why do LSRs need to do Hashing just up to the ELI+1? Can= 't they hash the whole label stack? If they can then, why is there a need f= or ELI? Thx Shahram -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net]=20 Sent: Friday, April 13, 2012 12:17 PM To: Shahram Davari Cc: Kireeti Kompella; mpls@ietf.org Subject: Re: entropy label draft: reserved label for ELI Hi Shahram, On Apr 12, 2012, at 18:01 , Shahram Davari wrote: > Hi Kireeti, >=20 > What is the relationship between this EL and the fat Label (RFC6391)? Same thing. > Can they both coexist? How many Entropy Labels can exist in a stack? How = many ELI can exist in a stack? Yes, they can coexist. In theoretical cases, there can be many entropy lab= els; each one, except the fat PW entropy label, must be preceded by an ELI. Practically speaking, there would be just one entropy label, either below t= he PW label (for fat PWs), or below the tunnel label (for all other apps, a= ssuming that's what we agree on). The main case for multiple entropy label= s is inter-provider hierarchical situations. HTH, Kireeti. > Thanks > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of K= ireeti Kompella > Sent: Thursday, April 12, 2012 12:48 PM > To: mpls@ietf.org > Subject: [mpls] entropy label draft: reserved label for ELI >=20 > Hi All, >=20 > Following up on the presentation at IETF 83, I promised to "take this to = the list". >=20 > The two questions are: > 1) should we make the ELI a "well-known" reserved label? > 2) should we associate the EL with tunnel labels or with application labe= ls? >=20 > This email is to poll the list about (1). >=20 > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the EL), r= ather than processing all labels in the label stack. >=20 > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means= of bailing out early from grabbing "deeper" fields (e.g., IP headers withi= n Ethernet within ...) for hashing. >=20 > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid = adding another entropy-label for the RSVP tunnel *if* the transit LSR finds= a reserved ELI already in the stack. Call this a 'short circuit' rule. >=20 > d) The short circuit rule can also be used for Carrier of Carrier VPNs an= d other situations with label hierarchy. >=20 > e) A reserved ELI obviates the need for upstream ELI allocation for mLDP = and P2MP RSVP-TE. >=20 > (Thanks to Shane for providing some of the above.) >=20 > The main drawback is the scarcity of reserved labels, which hopefully is = addressed by the pixie label draft. >=20 > So, the question is: should we make the ELI a reserved label? (If no, a = short reason would be helpful.) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 From jdrake@juniper.net Fri Apr 13 13:03:08 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0B821F858E for ; Fri, 13 Apr 2012 13:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUblLxp6pp05 for ; Fri, 13 Apr 2012 13:03:07 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9038921F858B for ; Fri, 13 Apr 2012 13:03:07 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT4iGea/IWx1E+7jrTL0AFF//xW5+YADG@postini.com; Fri, 13 Apr 2012 13:03:07 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 13 Apr 2012 13:03:00 -0700 From: John E Drake To: Gregory Mirsky , Kireeti Kompella , "mpls@ietf.org" Date: Fri, 13 Apr 2012 13:02:58 -0700 Thread-Topic: entropy labels: associate with tunnels or apps? Thread-Index: Ac0Y6btHeTBknJepS7aTKCASfz/9pgABoCNAAABNGFAAHUb5QAAPzM/QAAKBufA= Message-ID: <5E893DB832F57341992548CDBB333163A56E1F8FC7@EMBX01-HQ.jnpr.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <5E893DB832F57341992548CDBB333163A56E1F88C2@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A56E1F8C15@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:03:08 -0000 Greg, The EL draft has always described EL capability as a nodal property. Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: Friday, April 13, 2012 11:52 AM > To: John E Drake; Kireeti Kompella; mpls@ietf.org > Subject: RE: entropy labels: associate with tunnels or apps? >=20 > Hi John, > I think that "nodal capability" is too strong requirement in case of > per-interface label allocation. I think that in case of per-interface > label allocation interpretation of capability to process ELI/EL labels > can be limited to scope of that interface. >=20 > Regards, > Greg >=20 > -----Original Message----- > From: John E Drake [mailto:jdrake@juniper.net] > Sent: Friday, April 13, 2012 4:16 AM > To: Gregory Mirsky; Kireeti Kompella; mpls@ietf.org > Subject: RE: entropy labels: associate with tunnels or apps? >=20 > Greg, >=20 > Why do you make that coupling? It's not obvious to me that the label > allocation mode has anything to do with the ability to recognize and > discard ELI/EL label pairs. >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > > Sent: Thursday, April 12, 2012 5:52 PM > > To: John E Drake; Kireeti Kompella; mpls@ietf.org > > Subject: RE: entropy labels: associate with tunnels or apps? > > > > Hi John, > > this is not to answer Kireeti's question. > > I think that, strictly speaking, scope of "the ability to process > > entropy labels" depends on label allocation mode. For per-interface > it > > is an interface's capability. > > > > Regards, > > Greg > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of John E Drake > > Sent: Thursday, April 12, 2012 2:08 PM > > To: Kireeti Kompella; mpls@ietf.org > > Subject: Re: [mpls] entropy labels: associate with tunnels or apps? > > > > Yes, although I think the term 'associating the EL with tunnel > labels' > > and its variants are terrible. > > > > What we a really saying is that the ability to process entropy labels > > is a nodal capability that is indicated in the signaling of tunnels > to > > that node. > > > > We are also saying that the application is still responsible for > > creating the entropy label and for placing it in the MPLS label > stack. > > All we are doing is specifying a different order in which the > > application places labels in the stack. > > > > I think the most compelling reasons for specifying this order is that > > it makes the egress node processing uniform and amenable to hardware > > implementation, and that it ensures that the applications on the > > egress node are blissfully unaware of entropy labels. > > > > Sent from my iPhone > > > > > -----Original Message----- > > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On > Behalf > > > Of Kireeti Kompella > > > Sent: Thursday, April 12, 2012 1:21 PM > > > To: mpls@ietf.org > > > Subject: [mpls] entropy labels: associate with tunnels or apps? > > > > > > This email is about: 2) should we associate the EL with tunnel > > > labels or with application labels? > > > > > > NOTE: this is for all applications OTHER THAN LDP pseudowires, > where > > > we already have a solution. > > > > > > The philosophy here is that entropy labels are for improved ECMP; > > > tunnels have ECMP; apps are point-to-point-ish. > > > > > > Here's how it would work: an egress LSR signals, along with a > tunnel > > > (LDP or RSVP), its ability to process entropy labels. > > > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a > > > tunnel whose egress can process entropy labels, either decides not > > > to insert entropy labels, or: > > > 1. X hashes on the incoming packet, using its knowledge of the > > > application. > > > 2. X uses the result of the hash to choose the outgoing tunnel > label > > > TL 3. X makes an entropy label from the hash. > > > 4. X pushes the following label stack: > > > > > > Here are the benefits of associating the entropy label with > tunnels: > > > a) there are far fewer tunneling protocols than applications. > > > Standardizing, implementing, testing, and interop-ing entropy > labels > > > just for tunnels rather than for all apps (and doing it again in > the > > > future for new apps) is a huge win. > > > > > > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE > > for > > > specific ingress-egress pairs), the ingress can meaningfully > put/not > > > put ELs in the packet, based on the tunnel rather than the > > application. > > > > > > c) app label processing on the egress is unaffected. The label > > > stack that the egress would get (assuming PHP) is . > > > Preprocessing pops ELI+EL, leaving the processing of the AL the > same > > > as before. Processing (if the entropy label is associated > > > with the application) would mean touching the application label > > > processing microcode for each app, some of which (like VPLS) is > > fairly complex. > > > > > > d) the "app" of carrying IP over MPLS is no longer a special case. > > > [context: for IP over MPLS, as there is no app label, the label > > > stack has to be , not .] > > > > > > e) if multiple providers are involved in providing a service (CoC > > > VPNs, hierarchical tunnels, etc.), then each provider can > > autonomously > > > insert an entropy label for their tunnel. > > > > > > The downside is that the label stack has one more label because the > > > ELI would be mandatory: rather than . > > > > > > So, the question: should we associate ELs with tunnels rather than > > > with applications (apart from PWs)? (if no, a short reason why > > > would be > > > helpful.) > > > > > > Thanks, > > > Kireeti. > > > > > > _______________________________________________ > > > mpls mailing list > > > mpls@ietf.org > > > https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls From akatlas@gmail.com Fri Apr 13 13:16:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744DB21F85DD for ; Fri, 13 Apr 2012 13:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJbLBmVDG9A5 for ; Fri, 13 Apr 2012 13:16:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D512B21F85F1 for ; Fri, 13 Apr 2012 13:16:00 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2114439ggm.31 for ; Fri, 13 Apr 2012 13:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PWZkxYjiaqwaszH1dAjCiN0g3MwIfFGbNNw6+J9y67U=; b=sy9AtJ1fO4NOlMp6sp6KT+tYi3T9hxudVwLYUOCL+BsKPPTdk1ZSg51DvN4uENkd8G qVU9+aJKzyzukbqW3VvWKXPTVEsRRajZUw9ZSAKFf/vpceAOc4CMi/fANxtntEHzzUMj /E1jE8bfhAUhqiI16KhqrWUNgC7aqBFBb5LH+zTGSzX6FdyJQAS6Tj40UwoIwGJpLxqI rQ8XKVSH/v2wkAEvq6dGxZuw41+c7a9p2UDJhz3hfvtBr1L5FZZHhLRzcVDFHKcutDa1 9iZXmsoqNzqU8e9c2VOMX8zpcYr8SGgHdzv4uWP3vc6m3vEqVrfMSUqpufI3q2V9yR7Q GrSQ== MIME-Version: 1.0 Received: by 10.50.202.105 with SMTP id kh9mr2774955igc.68.1334348160330; Fri, 13 Apr 2012 13:16:00 -0700 (PDT) Received: by 10.50.1.209 with HTTP; Fri, 13 Apr 2012 13:16:00 -0700 (PDT) In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Date: Fri, 13 Apr 2012 16:16:00 -0400 Message-ID: From: Alia Atlas To: Kireeti Kompella Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:16:01 -0000 I support making the ELI a well-known reserved label. There is a benefit in intermediate LSRs being able to recognize the ELI and use the entropy label underneath for hashing. Alia On Thu, Apr 12, 2012 at 3:47 PM, Kireeti Kompella wro= te: > Hi All, > > Following up on the presentation at IETF 83, I promised to "take this to = the list". > > The two questions are: > 1) should we make the ELI a "well-known" reserved label? > 2) should we associate the EL with tunnel labels or with application labe= ls? > > This email is to poll the list about (1). > > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the EL), r= ather than processing all labels in the label stack. > > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a means= of bailing out early from grabbing "deeper" fields (e.g., IP headers withi= n Ethernet within ...) for hashing. > > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid = adding another entropy-label for the RSVP tunnel *if* the transit LSR finds= a reserved ELI already in the stack. =A0Call this a 'short circuit' rule. > > d) The short circuit rule can also be used for Carrier of Carrier VPNs an= d other situations with label hierarchy. > > e) A reserved ELI obviates the need for upstream ELI allocation for mLDP = and P2MP RSVP-TE. > > (Thanks to Shane for providing some of the above.) > > The main drawback is the scarcity of reserved labels, which hopefully is = addressed by the pixie label draft. > > So, the question is: should we make the ELI a reserved label? =A0(If no, = a short reason would be helpful.) > > Kireeti. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jdrake@juniper.net Fri Apr 13 13:17:49 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4703011E8095 for ; Fri, 13 Apr 2012 13:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogmlvG2NK5tO for ; Fri, 13 Apr 2012 13:17:48 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 239A321F85D3 for ; Fri, 13 Apr 2012 13:17:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT4iJ6WMhBqEEX1uoq+WijK+Byz3VSZ2k@postini.com; Fri, 13 Apr 2012 13:17:48 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Fri, 13 Apr 2012 13:15:40 -0700 From: John E Drake To: Shahram Davari , Kireeti Kompella Date: Fri, 13 Apr 2012 13:15:39 -0700 Thread-Topic: entropy label draft: reserved label for ELI Thread-Index: Ac0Y5SFw0c/KLlfeSf6xj8QqGuVmfAAKrnUgADUyNQAADn8kYAAbMDCg Message-ID: <5E893DB832F57341992548CDBB333163A56E1F8FE4@EMBX01-HQ.jnpr.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> <2C2F1EBA8050E74EA81502D5740B4BD6BC12CB9828@SJEXCHCCR02.corp.ad.broadcom.com> <18675970-8537-4A1B-8C0D-E9848F70AAE1@juniper.net> <4A6CE49E6084B141B15C0713B8993F2801F839@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <4A6CE49E6084B141B15C0713B8993F2801F839@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:17:49 -0000 Shahram, A transit LSR can use the whole label stack if it wishes. The ELI needs to= be there for the egress LSR, so it knows that an EL is included in the lab= el stack and can toss it (along with the ELI). Thanks, John=20 Sent from my iPhone > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Shahram Davari > Sent: Friday, April 13, 2012 12:24 PM > To: Kireeti Kompella > Cc: mpls@ietf.org > Subject: Re: [mpls] entropy label draft: reserved label for ELI >=20 > Thanks Kireeti, >=20 > One more question. Why do LSRs need to do Hashing just up to the ELI+1? > Can't they hash the whole label stack? If they can then, why is there a > need for ELI? >=20 > Thx > Shahram >=20 > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, April 13, 2012 12:17 PM > To: Shahram Davari > Cc: Kireeti Kompella; mpls@ietf.org > Subject: Re: entropy label draft: reserved label for ELI >=20 > Hi Shahram, >=20 > On Apr 12, 2012, at 18:01 , Shahram Davari wrote: >=20 > > Hi Kireeti, > > > > What is the relationship between this EL and the fat Label (RFC6391)? >=20 > Same thing. >=20 > > Can they both coexist? How many Entropy Labels can exist in a stack? > How many ELI can exist in a stack? >=20 > Yes, they can coexist. In theoretical cases, there can be many entropy > labels; each one, except the fat PW entropy label, must be preceded by > an ELI. >=20 > Practically speaking, there would be just one entropy label, either > below the PW label (for fat PWs), or below the tunnel label (for all > other apps, assuming that's what we agree on). The main case for > multiple entropy labels is inter-provider hierarchical situations. >=20 > HTH, > Kireeti. >=20 > > Thanks > > Shahram > > > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > Of Kireeti Kompella > > Sent: Thursday, April 12, 2012 12:48 PM > > To: mpls@ietf.org > > Subject: [mpls] entropy label draft: reserved label for ELI > > > > Hi All, > > > > Following up on the presentation at IETF 83, I promised to "take this > to the list". > > > > The two questions are: > > 1) should we make the ELI a "well-known" reserved label? > > 2) should we associate the EL with tunnel labels or with application > labels? > > > > This email is to poll the list about (1). > > > > Making the ELI a reserved label has the following benefits: > > a) Transit LSRs can hash on labels up to the ELI and one more (the > EL), rather than processing all labels in the label stack. > > > > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a > means of bailing out early from grabbing "deeper" fields (e.g., IP > headers within Ethernet within ...) for hashing. > > > > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can > avoid adding another entropy-label for the RSVP tunnel *if* the transit > LSR finds a reserved ELI already in the stack. Call this a 'short > circuit' rule. > > > > d) The short circuit rule can also be used for Carrier of Carrier > VPNs and other situations with label hierarchy. > > > > e) A reserved ELI obviates the need for upstream ELI allocation for > mLDP and P2MP RSVP-TE. > > > > (Thanks to Shane for providing some of the above.) > > > > The main drawback is the scarcity of reserved labels, which hopefully > is addressed by the pixie label draft. > > > > So, the question is: should we make the ELI a reserved label? (If > no, a short reason would be helpful.) > > > > Kireeti. > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From shane@castlepoint.net Fri Apr 13 13:59:53 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B752D21F8746 for ; Fri, 13 Apr 2012 13:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txpgnZVurzns for ; Fri, 13 Apr 2012 13:59:53 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2447C21F8740 for ; Fri, 13 Apr 2012 13:59:53 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 926BE268063; Fri, 13 Apr 2012 14:59:52 -0600 (MDT) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 13 Apr 2012 14:59:52 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=54461; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> Date: Fri, 13 Apr 2012 14:59:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <33916C8A-C4C8-41C4-9F10-F28621BDB8EC@castlepoint.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> To: Kireeti Kompella X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 20:59:53 -0000 On Apr 12, 2012, at 1:47 PM, Kireeti Kompella wrote: > The two questions are: > 1) should we make the ELI a "well-known" reserved label? Yes, please. I think that this should vastly simplify label processing = by both transit and egress LSR/LER's and in the cases of upstream = assigned labels (p2mp LSP's), to mention but a few of the positive = benefits. -shane > 2) should we associate the EL with tunnel labels or with application = labels? >=20 > This email is to poll the list about (1). >=20 > Making the ELI a reserved label has the following benefits: > a) Transit LSRs can hash on labels up to the ELI and one more (the = EL), rather than processing all labels in the label stack. >=20 > b) Similar to (a), transit LSRs could use a Reserved ELI Label as a = means of bailing out early from grabbing "deeper" fields (e.g., IP = headers within Ethernet within ...) for hashing. >=20 > c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can = avoid adding another entropy-label for the RSVP tunnel *if* the transit = LSR finds a reserved ELI already in the stack. Call this a 'short = circuit' rule. >=20 > d) The short circuit rule can also be used for Carrier of Carrier VPNs = and other situations with label hierarchy. >=20 > e) A reserved ELI obviates the need for upstream ELI allocation for = mLDP and P2MP RSVP-TE. >=20 > (Thanks to Shane for providing some of the above.) >=20 > The main drawback is the scarcity of reserved labels, which hopefully = is addressed by the pixie label draft. >=20 > So, the question is: should we make the ELI a reserved label? (If no, = a short reason would be helpful.) >=20 > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rmanur@broadcom.com Fri Apr 13 14:04:21 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6C911E8100 for ; Fri, 13 Apr 2012 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wONKbUpohKC5 for ; Fri, 13 Apr 2012 14:04:20 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E28A11E80E4 for ; Fri, 13 Apr 2012 14:04:16 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 13 Apr 2012 14:14:34 -0700 X-Server-Uuid: 72204117-5C29-4314-8910-60DB108979CB Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB02.corp.ad.broadcom.com (10.16.192.232) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 13 Apr 2012 14:04:08 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 14:03:57 -0700 From: "Rajeev Manur" To: "Kireeti Kompella" , "shane@level3.net" Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0ZiHepB6t2loYdRx+hrEz0TIkrpAACI0QQAAmNQqA= Date: Fri, 13 Apr 2012 21:03:57 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.75.38] MIME-Version: 1.0 X-WSS-ID: 639648B03IO4572801-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "mpls@ietf.org" Subject: [mpls] FW: MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:04:21 -0000 SGkgQWxsLA0KDQpJIGFtIHRyeWluZyB0byBnZXQgbW9yZSBjbGFyaXR5IG9uIHRoZSBqdXN0aWZp Y2F0aW9uIGZvciB1c2luZyBhbiBFTEkuIFRoYW5rcyB0byBLaXJlZXRpIGZvciBoaXMgZmVlZGJh Y2suIEkgaGF2ZSBvbmUgbW9yZSBxdWVzdGlvbiBhZGRlZCBpbmxpbmUgYmVsb3cuIEFkZGluZyB0 aGUgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdCBzbyB0aGF0IG90aGVycyBjYW4gYWxzbyBjaGltZSBp bi4NCg0KVGhhbmtzICENCi0tUmFqZWV2DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpIaSBLaXJlZXRpLA0KDQo+ SSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUganVzdGlmaWNhdGlvbiBmb3IgdXNpbmcgYSBF TEkgaW5zdGVhZCBvZiB1c2luZyBUTCBsYWJlbCBjb250ZXh0IHRvIGluZGljYXRlIHRoZSBwcmVz ZW5jZSA+b2YgRUwgbGFiZWwsDQoNCklmIHlvdSBtZWFuLCBldmVyeW9uZSBhZHZlcnRpc2UgdHdv IExEUCBsYWJlbHMsIG9uZSBmb3IgRUwsIG9uZSB3aXRob3V0LCB0aGF0IHdhcyBhIG5vbi1zdGFy dGVyIC4uLiB0aGF0IGRvdWJsZXMgc3RhdGUgaW4gdGhlIGNvcmUsIGFuZCB3b3JzZSB3aGVuIHlv dSBmYWN0b3IgaW4gTEZBLg0KDQpbUmFqZWV2XSBXaHkgZG8gd2UgbmVlZCAyIExTUHMuIEFuIExT UCBlaXRoZXIgaGFzIEVMIG9yIGl0IGRvZXMnbnQ/IElmIHdlIGhhdmUgYW4gTFNQIHdpdGggRUws IHRoZW4gYWxsIExTUnMgdGhhdCBwdXNoIG5ha2VkIElQIGludG8gdGhlIExTUCB3b3VsZCBoYXZl IHRvIGFkZCBlbnRyb3B5IGxhYmVsLiBJcyB5b3VyIGludGVudCB0byBrZWVwIHRoZSB0cmFuc2l0 IExTUnMgaXNvbGF0ZWQgZnJvbSBoYXZpbmcgdG8gY29tcHV0ZS9hZGQgRUw/DQoNClRoYW5rcyAh DQotLVJhamVldg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2lyZWV0aSBL b21wZWxsYSBbbWFpbHRvOmtpcmVldGlAanVuaXBlci5uZXRdIA0KU2VudDogRnJpZGF5LCBBcHJp bCAxMywgMjAxMiA4OjE3IEFNDQpUbzogUmFqZWV2IE1hbnVyDQpDYzogc2hhbmVAbGV2ZWwzLm5l dA0KU3ViamVjdDogUmU6IE1QTFMgZW50cm9weSA6IGNsYXJpZmljYXRpb24NCg0KSGkgUmFqZWV2 LA0KDQpPbiBBcHIgMTIsIDIwMTIsIGF0IDE5OjIyLCAiUmFqZWV2IE1hbnVyIiA8cm1hbnVyQGJy b2FkY29tLmNvbTxtYWlsdG86cm1hbnVyQGJyb2FkY29tLmNvbT4+IHdyb3RlOg0KDQoNCkhpIFNo YW5lL0tpcmVldGksDQoNCkkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGp1c3RpZmljYXRp b24gZm9yIHVzaW5nIGEgRUxJIGluc3RlYWQgb2YgdXNpbmcgVEwgbGFiZWwgY29udGV4dCB0byBp bmRpY2F0ZSB0aGUgcHJlc2VuY2Ugb2YgRUwgbGFiZWwsDQoNCklmIHlvdSBtZWFuLCBldmVyeW9u ZSBhZHZlcnRpc2UgdHdvIExEUCBsYWJlbHMsIG9uZSBmb3IgRUwsIG9uZSB3aXRob3V0LCB0aGF0 IHdhcyBhIG5vbi1zdGFydGVyIC4uLiB0aGF0IGRvdWJsZXMgc3RhdGUgaW4gdGhlIGNvcmUsIGFu ZCB3b3JzZSB3aGVuIHlvdSBmYWN0b3IgaW4gTEZBLg0KDQpJZiB5b3UgbWVhbiBzb21ldGhpbmcg ZWxzZSwgeW91J2xsIGhhdmUgdG8gZXhwbGFpbi4NCg0Kc2ltaWxhciB0byB3aGF0IHdlIGRvIGZv ciBQVyBGQVQuDQoNClRoaXMgSSBkb24ndCB1bmRlcnN0YW5kLg0KDQpJIHRyYWNrZWQgZG93biB0 aGlzIG9sZCBjb252IG9uIHRoZSBXRyBtYWlsaW5nIGxpc3Qgd2l0aCB5b3VyIHJlc3BvbnNlLg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KT24gSnVsIDI3LCAyMDEwLCBhdCAwNzoy NCAsIFN0ZXdhcnQgQnJ5YW50IHdyb3RlOg0KPiBKb2huDQo+DQo+IFdoeSBkbyB5b3UgcHJlZmVy IHRvIHVzZSBhbiBFTEkgYXMgb3Bwb3NlZCB0byB1c2luZyBhIG5ldyBzZXQgb2YgRkVDcyB3aXRo IHRoZSBwcm9wZXJ0eSB0aGF0IHRoZXkgYXJlIGZvbGxvd2VkIGJ5IGFuIEVMPw0KDQpUaGUgRUxJ IGlzIGEgY2F0Y2gtYWxsLCBpbiBjYXNlIHRoZXJlIGlzIGFueSBwb3RlbnRpYWwgY29uZnVzaW9u IHRoYXQgdGhlIEVMIG1heSBiZSBpbnRlcnByZXRlZCBhcyBhbiBhcHAgbGFiZWwuICBNb3N0IGFw cCBsYWJlbHMgKFBXcyAodmlhIFQtTERQIG9yIEJHUCksIFZQTiBsYWJlbHMsIGV0Yy4pIGNhbiBl YXNpbHkgYmUgZm9sbG93ZWQgYnkgYW4gRUwsIGFzIFNoYW5lJ3Mgc2xpZGVzIHNob3dlZC4gIE5v IG5lZWQgZm9yIG5ldyBGRUNzLg0KDQpUaGUgc3RpY2t5IGNhc2UgaXMgIm5ha2VkIiBJUCBvdmVy IExEUCB0dW5uZWxzLiAgRG8geW91IGhhdmUgYSBzdWdnZXN0aW9uIHRoYXQgZG9lc24ndCBuZWVk IGFuIEVMSSBpbiB0aGF0IGNhc2U/DQoNClRoYW5rcywNCktpcmVldGkuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpBZ3JlZWQsIExTUHMgY2FuIGNhcnJ5IG5ha2VkIElQIG9yIE1Q TFMgdHJhZmZpYy4gT25lIGlzc3VlIEkgc2VlIHdpdGggTERQIHR1bm5lbHMgaXMgdGhhdCBJUCB0 cmFmZmljIGNhbiBiZSBwdXNoZWQgaW50byBhIExEUCBsc3AgZnJvbSBhbnkgaG9wIGFsb25nIHRo ZSBMU1AuIFRvIG1ha2UgdGhpcyB3b3JrIGZvciBFTCB3aXRob3V0IEVMSSB3ZSB3b3VsZCBoYXZl IHRvIHN0b3JlIHRoZSBFTCBzaWduYWxpbmcgc3RhdGUgYXQgYWxsIGhvcHMgYWxvbmcgdGhlIExE UCBsc3AuIElzIHRoYXQgdGhlIGlzc3VlPyBJZiB3ZSBkaWQgaGF2ZSB0aGUgc3RhdGUsIHRoZW4g d2hlbiBhbnkgaG9wIHB1c2hlcyBJUCBpbnRvIGEgTERQIExzcCwgaXQgd291bGQgYWxzbyBrbm93 IGlmIGl0IG5lZWRzIHRvIGFkZCBhIEVMIGxhYmVsIGFuZCB0aGlzIGlzc3VlIHdvdWxkIGdvIGF3 YXksIHJpZ2h0PyBJIHdvdWxkIHJlYWxseSBhcHByZWNpYXRlIGFueSBwb2ludGVycy4NCg0KQWN0 dWFsbHksIGVpdGhlciB3YXksIHRoZSBjb250cm9sIHBsYW5lIGNhcnJpZXMgdGhlIEVMLWNhcGFi aWxpdHkgc3RhdGUsIGJ1dCB0aGF0J3MganVzdCBhbiBhZGRpdGlvbmFsIGJpdC4gIFdpdGggc2Vw YXJhdGUgRkVDcywgdGhlcmUncyBkYXRhIHBsYW5lIHN0YXRlIGFzIHdlbGwsIGFuZCB0aGF0J3Mg YSBsb3Qgd29yc2UuDQoNCkhUSCwNCktpcmVldGkNCg0KVGhhbmtzICENCi0tUmFqZWV2DQoNCj4g U3Rld2FydA0KDQoNCg== From kireeti@juniper.net Fri Apr 13 14:55:35 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B3911E8146 for ; Fri, 13 Apr 2012 14:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekuAlOkwx8dl for ; Fri, 13 Apr 2012 14:55:35 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34911E8143 for ; Fri, 13 Apr 2012 14:55:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKT4ig1Y77XhqyheMBZUwCsGE1rCQo+Snu@postini.com; Fri, 13 Apr 2012 14:55:34 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Apr 2012 14:55:17 -0700 From: Kireeti Kompella To: Rajeev Manur Date: Fri, 13 Apr 2012 14:55:14 -0700 Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0ZwBxgjnKuQIY2Q325wkYmchNF7A== Message-ID: <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:55:35 -0000 Hi Rajeev, On Apr 13, 2012, at 14:04, "Rajeev Manur" wrote: > [Rajeev] Why do we need 2 LSPs. An LSP either has EL or it does'nt? Not true today.=20 > If we have an LSP with EL, then all LSRs that push naked IP into the LSP = would have to add entropy label. And if a particular ingress is not capable of inserting an EL? Kireeti From jdrake@juniper.net Fri Apr 13 15:07:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD3421F847D for ; Fri, 13 Apr 2012 15:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVlhuYmOU2vc for ; Fri, 13 Apr 2012 15:07:04 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8A21F844D for ; Fri, 13 Apr 2012 15:07:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT4ijg6sggNF/jo2YePdDrYh4kbnP++nT@postini.com; Fri, 13 Apr 2012 15:07:03 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 13 Apr 2012 15:06:51 -0700 From: John E Drake To: Kireeti Kompella , Rajeev Manur Date: Fri, 13 Apr 2012 15:06:50 -0700 Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0ZwBxgjnKuQIY2Q325wkYmchNF7AAAW8vA Message-ID: <5E893DB832F57341992548CDBB333163A56E1F912C@EMBX01-HQ.jnpr.net> References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> In-Reply-To: <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:07:04 -0000 Snipped... Sent from my iPhone >=20 > > If we have an LSP with EL, then all LSRs that push naked IP into the > LSP would have to add entropy label. >=20 > And if a particular ingress is not capable of inserting an EL? [JD] Then it should be disciplined?=20 >=20 > Kireeti >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Fri Apr 13 15:42:13 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E510011E8135 for ; Fri, 13 Apr 2012 15:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Husoox5xKHqL for ; Fri, 13 Apr 2012 15:42:13 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5DB11E8130 for ; Fri, 13 Apr 2012 15:42:13 -0700 (PDT) Received: by iazz13 with SMTP id z13so5798977iaz.31 for ; Fri, 13 Apr 2012 15:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=c+ZhBsv536o9tPrw4fMKalaJupcuMvYbnCTjTPX+ueA=; b=JmVm9mcvL8PWS/tokDvPGRwAlC8o3kvRnezLLnXFZMv6PlaB8Zltfr67UgFdaJzhK5 Cu5fJ3uxsn/Os4x4zIVsUIVH0qLk+SUoqWkjSLDZX5r0BAl0gHJ6E6mw2nmQMgkQvt2s K7SUnPbzcDAcu+E8mF2BSGIc0IWjLAb2vQHc/p4Xvzm9w3bN9WARP3SYpqHVtrHFkXRx kDiyNRzDUYNFptnVyH83hePqDIF3QDnzhX0yTTUSSDgyveFDfOpX97jg0lAHdChztYPx F/3Q2MWe+KZJEza8+Oc/7CNByX6aQlBE54CCbFUxjFeTbc/CZh4VFqmaSGWWsrXAi3wv K61A== Received: by 10.50.179.104 with SMTP id df8mr2966208igc.11.1334356932592; Fri, 13 Apr 2012 15:42:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.184.231 with HTTP; Fri, 13 Apr 2012 15:41:52 -0700 (PDT) In-Reply-To: <33916C8A-C4C8-41C4-9F10-F28621BDB8EC@castlepoint.net> References: <7ED7E703-9E0D-45DB-919B-854AB546B738@juniper.net> <33916C8A-C4C8-41C4-9F10-F28621BDB8EC@castlepoint.net> From: "Andrew G. Malis" Date: Fri, 13 Apr 2012 18:41:52 -0400 Message-ID: To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy label draft: reserved label for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 22:42:14 -0000 I completely agree with Shane. Cheers, Andy On Fri, Apr 13, 2012 at 4:59 PM, Shane Amante wrote= : > > On Apr 12, 2012, at 1:47 PM, Kireeti Kompella wrote: >> The two questions are: >> 1) should we make the ELI a "well-known" reserved label? > > Yes, please. =A0I think that this should vastly simplify label processing= by both transit and egress LSR/LER's and in the cases of upstream assigned= labels (p2mp LSP's), to mention but a few of the positive benefits. > > -shane > > >> 2) should we associate the EL with tunnel labels or with application lab= els? >> >> This email is to poll the list about (1). >> >> Making the ELI a reserved label has the following benefits: >> a) Transit LSRs can hash on labels up to the ELI and one more (the EL), = rather than processing all labels in the label stack. >> >> b) Similar to (a), transit LSRs could use a Reserved ELI Label as a mean= s of bailing out early from grabbing "deeper" fields (e.g., IP headers with= in Ethernet within ...) for hashing. >> >> c) Transit LSRs, (particularly ones doing LDP/RSVP tunneling), can avoid= adding another entropy-label for the RSVP tunnel *if* the transit LSR find= s a reserved ELI already in the stack. =A0Call this a 'short circuit' rule. >> >> d) The short circuit rule can also be used for Carrier of Carrier VPNs a= nd other situations with label hierarchy. >> >> e) A reserved ELI obviates the need for upstream ELI allocation for mLDP= and P2MP RSVP-TE. >> >> (Thanks to Shane for providing some of the above.) >> >> The main drawback is the scarcity of reserved labels, which hopefully is= addressed by the pixie label draft. >> >> So, the question is: should we make the ELI a reserved label? =A0(If no,= a short reason would be helpful.) >> >> Kireeti. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rmanur@broadcom.com Fri Apr 13 16:02:43 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A174411E814B for ; Fri, 13 Apr 2012 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY9ZMZiP7j5Z for ; Fri, 13 Apr 2012 16:02:43 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2615811E813A for ; Fri, 13 Apr 2012 16:02:04 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 13 Apr 2012 16:11:37 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.11) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 13 Apr 2012 16:01:53 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 16:01:52 -0700 From: "Rajeev Manur" To: "Kireeti Kompella" Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0ZiHepB6t2loYdRx+hrEz0TIkrpAACI0QQAAmNQqAAEONjAAANxw9A Date: Fri, 13 Apr 2012 23:01:52 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED03182D@SJEXCHMB12.corp.ad.broadcom.com> References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> In-Reply-To: <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.75.38] MIME-Version: 1.0 X-WSS-ID: 63966D233E017610355-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 23:02:43 -0000 Hi Kireeti, Please see inline... -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net]=20 Sent: Friday, April 13, 2012 2:55 PM To: Rajeev Manur Cc: shane@level3.net; mpls@ietf.org Subject: Re: MPLS entropy : clarification on the need for ELI Hi Rajeev, On Apr 13, 2012, at 14:04, "Rajeev Manur" wrote: > [Rajeev] Why do we need 2 LSPs. An LSP either has EL or it does'nt? Not true today. <> Not sure what you mean. Do you mean existing implementations of = EL for such LSPs? =20 > If we have an LSP with EL, then all LSRs that push naked IP into the LSP = would have to add entropy label. And if a particular ingress is not capable of inserting an EL? <> Ok, if the LSR is not capable of inserting an EL, then there is = a problem. We either have to use 'ELI' as proposed in this draft and make t= he packet self identifying, Or use separate TL labels for EL-aware and non-= EL-aware Lsps. Later, obviously has its own issues. Q1 : Is this only reason for adding ELI? Q2 : If yes, have we looked at other possible ways of working around the = problem. For example if such LSRs are capable of inserting at least 2 label= s, then we should be able to program such boxes to add second dummy label (= EL=3D"fixed value"). Kireeti From shane@castlepoint.net Fri Apr 13 17:19:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D2911E80AA for ; Fri, 13 Apr 2012 17:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khHQXDA8MnE1 for ; Fri, 13 Apr 2012 17:19:15 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0201611E8088 for ; Fri, 13 Apr 2012 17:18:37 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DACD7268063; Fri, 13 Apr 2012 18:18:36 -0600 (MDT) Received: from mbpw.castlepoint.net (65-101-252-129.hlrn.qwest.net [65.101.252.129]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 13 Apr 2012 18:18:36 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=65.101.252.129; client-port=55599; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> Date: Fri, 13 Apr 2012 18:18:20 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9EC61509-064A-41D7-9A61-3DA6298A34C8@castlepoint.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> To: Kireeti Kompella X-Mailer: Apple Mail (2.1257) Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:19:16 -0000 Kireeti, All, On Apr 12, 2012, at 2:20 PM, Kireeti Kompella wrote: > This email is about: 2) should we associate the EL with tunnel labels = or with application labels? EL's with tunnel labels. Definitely, tunnel labels. IMO, the most compelling reasons are (in addition to those you've = already provided below): 1) We solve for entropy labels _once_ at the tunnel-layer and we're = done. IOW, entropy-labels should become a first-class citizen of the = overall MPLS architecture, which is goodness. 2) As an SP, testing entropy-labels at the tunnel layer in all future = HW/SW releases that gets pushed out to the network is _much_ more = straightforward. In summary, I would expect it to be much easier to = _understand_ and see when entropy-labels are being used at the tunnel = layer vs. when & why they are not. IOW, when troubleshooting it will be = much more noticeable that _ALL_ traffic is getting fine-grained = load-balancing between a pair of PE's, i.e.: at the tunnel-layer, = compared to the machinations one may have to go through to figure out if = a _set_ of applications on a PE are _each_ "doing the right thing" wrt = signaling entropy-labels for themselves. One more thing below. > NOTE: this is for all applications OTHER THAN LDP pseudowires, where = we already have a solution. >=20 > The philosophy here is that entropy labels are for improved ECMP; = tunnels have ECMP; apps are point-to-point-ish. >=20 > Here's how it would work: an egress LSR signals, along with a tunnel = (LDP or RSVP), its ability to process entropy labels. > An ingress LSR X, when it resolves an application (e.g. L3VPN) to a = tunnel whose egress can process entropy labels, either decides not to = insert entropy labels, or: > 1. X hashes on the incoming packet, using its knowledge of the = application. > 2. X uses the result of the hash to choose the outgoing tunnel label = TL > 3. X makes an entropy label from the hash. > 4. X pushes the following label stack: >=20 > Here are the benefits of associating the entropy label with tunnels: > a) there are far fewer tunneling protocols than applications. = Standardizing, implementing, testing, and interop-ing entropy labels = just for tunnels rather than for all apps (and doing it again in the = future for new apps) is a huge win. >=20 > b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for = specific ingress-egress pairs), the ingress can meaningfully put/not put = ELs in the packet, based on the tunnel rather than the application. >=20 > c) app label processing on the egress is unaffected. The label stack = that the egress would get (assuming PHP) is . = Preprocessing pops ELI+EL, leaving the processing of the AL the same as = before. Processing (if the entropy label is associated with = the application) would mean touching the application label processing = microcode for each app, some of which (like VPLS) is fairly complex. >=20 > d) the "app" of carrying IP over MPLS is no longer a special case. = [context: for IP over MPLS, as there is no app label, the label stack = has to be , not .] >=20 > e) if multiple providers are involved in providing a service (CoC = VPNs, hierarchical tunnels, etc.), then each provider can autonomously = insert an entropy label for their tunnel. >=20 > The downside is that the label stack has one more label because the = ELI would be mandatory: rather than . I am not concerned, in the least, of "burning" an extra 4-Bytes on the = wire for an always present ELI: a) all links are already configured for = Jumbo frames and will not even notice an extra 4-Bytes; and, b) this is = an extremely small price to pay (sorry for the pun), for the substantial = and significant CapEx & OpEx savings for ensuring [very] good, = fine-grained load-balancing over LAG & ECMP paths in the Core. > So, the question: should we associate ELs with tunnels rather than = with applications (apart from PWs)? (if no, a short reason why would be = helpful.) EL's with tunnels, please! -shane > Thanks, > Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti@juniper.net Fri Apr 13 17:21:42 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999C211E80B4 for ; Fri, 13 Apr 2012 17:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09q4hfsiqKNI for ; Fri, 13 Apr 2012 17:21:42 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87311E8096 for ; Fri, 13 Apr 2012 17:21:41 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT4jDFMzCoxtzLbKYJ+1Iba2gq0+smX5Z@postini.com; Fri, 13 Apr 2012 17:21:41 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 13 Apr 2012 17:21:36 -0700 From: Kireeti Kompella To: Rajeev Manur Date: Fri, 13 Apr 2012 17:21:33 -0700 Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0Z1I0nVZpellH/Rde2i/d+MMt2nw== Message-ID: References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> <1E714095C88C9D408749A723A59CF6ED03182D@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <1E714095C88C9D408749A723A59CF6ED03182D@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:21:42 -0000 On Apr 13, 2012, at 16:02, "Rajeev Manur" wrote: > Q2 : If yes, have we looked at other possible ways of working around the = problem. For example if such LSRs are capable of inserting at least 2 label= s, then we should be able to program such boxes to add second dummy label (= EL=3D"fixed value"). The problem is only partly "can it?". Even if it could, it doesn't at prese= nt. So, if you upgrade one LER to do ELs, no one else can talk to it until = they too are upgraded. All-or-nothing upgrade policies are not the best way= to make friends with network operators :-) Kireeti From akatlas@gmail.com Fri Apr 13 17:28:18 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A519411E80E0 for ; Fri, 13 Apr 2012 17:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ciLX44T5Ld+Y for ; Fri, 13 Apr 2012 17:28:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D58FA11E80B4 for ; Fri, 13 Apr 2012 17:28:17 -0700 (PDT) Received: by iazz13 with SMTP id z13so5904338iaz.31 for ; Fri, 13 Apr 2012 17:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=b/XR+gQLC0cUGCU3V5KNlVX4LqPTVhbhkgjqvlVVN88=; b=wQxehJikid1p/NT9PJe37Rt3QANSmIaHhQCZQPb4K7GZltG2WCxNYildYohyfwRvgW uuZXGrTpmx4XX8GUpYnNYajB7QVQeIs5naOh92G8Uj66VXX3vhT5nkxpX4yJT9Kkknbq UwxZ07gaFyPdAtkIH1MODPkE8eTbhMma2pFzv7UJF6py+aB8evbdeGdQpFvHaVnrOM4v FfM4LM9NoFw+MiNEHVq42z68CcSODV8XZdTFAlRQ7mpokOyd33lW05CbRWoTolIaSTPK bZFm9G0FSFv3OsYl8O2Sig15QyDuG5YZRuAEU+snxmB9LXsS/iDPn4nNoqCWPynUA9wB khvQ== MIME-Version: 1.0 Received: by 10.50.186.168 with SMTP id fl8mr60502igc.68.1334363297474; Fri, 13 Apr 2012 17:28:17 -0700 (PDT) Received: by 10.50.1.209 with HTTP; Fri, 13 Apr 2012 17:28:17 -0700 (PDT) In-Reply-To: <9EC61509-064A-41D7-9A61-3DA6298A34C8@castlepoint.net> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <9EC61509-064A-41D7-9A61-3DA6298A34C8@castlepoint.net> Date: Fri, 13 Apr 2012 20:28:17 -0400 Message-ID: From: Alia Atlas To: Shane Amante Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:28:18 -0000 I agree with Shane & Kireeti - ELs at the tuunel-layer so it is solved once and done. Alia On Fri, Apr 13, 2012 at 8:18 PM, Shane Amante wrote= : > Kireeti, All, > > On Apr 12, 2012, at 2:20 PM, Kireeti Kompella wrote: >> This email is about: 2) should we associate the EL with tunnel labels or= with application labels? > > EL's with tunnel labels. =A0Definitely, tunnel labels. > > IMO, the most compelling reasons are (in addition to those you've already= provided below): > 1) =A0We solve for entropy labels _once_ at the tunnel-layer and we're do= ne. =A0IOW, entropy-labels should become a first-class citizen of the overa= ll MPLS architecture, which is goodness. > 2) =A0As an SP, testing entropy-labels at the tunnel layer in all future = HW/SW releases that gets pushed out to the network is _much_ more straightf= orward. =A0In summary, I would expect it to be much easier to _understand_ = and see when entropy-labels are being used at the tunnel layer vs. when & w= hy they are not. =A0IOW, when troubleshooting it will be much more noticeab= le that _ALL_ traffic is getting fine-grained load-balancing between a pair= of PE's, i.e.: at the tunnel-layer, compared to the machinations one may h= ave to go through to figure out if a _set_ of applications on a PE are _eac= h_ "doing the right thing" wrt signaling entropy-labels for themselves. > > One more thing below. > >> NOTE: this is for all applications OTHER THAN LDP pseudowires, where we = already have a solution. >> >> The philosophy here is that entropy labels are for improved ECMP; tunnel= s have ECMP; apps are point-to-point-ish. >> >> Here's how it would work: an egress LSR signals, along with a tunnel (LD= P or RSVP), its ability to process entropy labels. >> An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tunn= el whose egress can process entropy labels, either decides not to insert en= tropy labels, or: >> 1. X hashes on the incoming packet, using its knowledge of the applicati= on. >> 2. X uses the result of the hash to choose the outgoing tunnel label TL >> 3. X makes an entropy label from the hash. >> 4. X pushes the following label stack: >> >> Here are the benefits of associating the entropy label with tunnels: >> a) there are far fewer tunneling protocols than applications. =A0Standar= dizing, implementing, testing, and interop-ing entropy labels just for tunn= els rather than for all apps (and doing it again in the future for new apps= ) is a huge win. >> >> b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for s= pecific ingress-egress pairs), the ingress can meaningfully put/not put ELs= in the packet, based on the tunnel rather than the application. >> >> c) app label processing on the egress is unaffected. =A0The label stack = that the egress would get (assuming PHP) is . =A0Preprocessing= pops ELI+EL, leaving the processing of the AL the same as before. =A0Proce= ssing (if the entropy label is associated with the application) wo= uld mean touching the application label processing microcode for each app, = some of which (like VPLS) is fairly complex. >> >> d) the "app" of carrying IP over MPLS is no longer a special case. =A0[c= ontext: for IP over MPLS, as there is no app label, the label stack has to = be , not .] >> >> e) if multiple providers are involved in providing a service (CoC VPNs, = hierarchical tunnels, etc.), then each provider can autonomously insert an = entropy label for their tunnel. >> >> The downside is that the label stack has one more label because the ELI = would be mandatory: rather than . > > I am not concerned, in the least, of "burning" an extra 4-Bytes on the wi= re for an always present ELI: a) all links are already configured for Jumbo= frames and will not even notice an extra 4-Bytes; and, b) this is an extre= mely small price to pay (sorry for the pun), for the substantial and signif= icant CapEx & OpEx savings for ensuring [very] good, fine-grained load-bala= ncing over LAG & ECMP paths in the Core. > > >> So, the question: should we associate ELs with tunnels rather than with = applications (apart from PWs)? =A0(if no, a short reason why would be helpf= ul.) > > EL's with tunnels, please! > > -shane > > >> Thanks, >> Kireeti. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jeff.tantsura@ericsson.com Fri Apr 13 17:29:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782C811E8105 for ; Fri, 13 Apr 2012 17:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Srx8PKlhc-X5 for ; Fri, 13 Apr 2012 17:29:37 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A2E8011E80E0 for ; Fri, 13 Apr 2012 17:29:37 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3E0TCrs018713; Fri, 13 Apr 2012 19:29:13 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 13 Apr 2012 20:29:06 -0400 From: Jeff Tantsura To: Alia Atlas Date: Fri, 13 Apr 2012 20:29:01 -0400 Thread-Topic: [mpls] entropy labels: associate with tunnels or apps? Thread-Index: Ac0Z1Zn3aiYgo5mKTWK4FddDfwv2aw== Message-ID: <465E5F23-DFB1-438B-8DCE-40B414638C52@ericsson.com> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <9EC61509-064A-41D7-9A61-3DA6298A34C8@castlepoint.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 00:29:38 -0000 +1 Regards, Jeff On Apr 13, 2012, at 17:28, "Alia Atlas" wrote: > I agree with Shane & Kireeti - ELs at the tuunel-layer so it is solved > once and done. >=20 > Alia >=20 > On Fri, Apr 13, 2012 at 8:18 PM, Shane Amante wro= te: >> Kireeti, All, >>=20 >> On Apr 12, 2012, at 2:20 PM, Kireeti Kompella wrote: >>> This email is about: 2) should we associate the EL with tunnel labels o= r with application labels? >>=20 >> EL's with tunnel labels. Definitely, tunnel labels. >>=20 >> IMO, the most compelling reasons are (in addition to those you've alread= y provided below): >> 1) We solve for entropy labels _once_ at the tunnel-layer and we're don= e. IOW, entropy-labels should become a first-class citizen of the overall = MPLS architecture, which is goodness. >> 2) As an SP, testing entropy-labels at the tunnel layer in all future H= W/SW releases that gets pushed out to the network is _much_ more straightfo= rward. In summary, I would expect it to be much easier to _understand_ and= see when entropy-labels are being used at the tunnel layer vs. when & why = they are not. IOW, when troubleshooting it will be much more noticeable th= at _ALL_ traffic is getting fine-grained load-balancing between a pair of P= E's, i.e.: at the tunnel-layer, compared to the machinations one may have t= o go through to figure out if a _set_ of applications on a PE are _each_ "d= oing the right thing" wrt signaling entropy-labels for themselves. >>=20 >> One more thing below. >>=20 >>> NOTE: this is for all applications OTHER THAN LDP pseudowires, where we= already have a solution. >>>=20 >>> The philosophy here is that entropy labels are for improved ECMP; tunne= ls have ECMP; apps are point-to-point-ish. >>>=20 >>> Here's how it would work: an egress LSR signals, along with a tunnel (L= DP or RSVP), its ability to process entropy labels. >>> An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tun= nel whose egress can process entropy labels, either decides not to insert e= ntropy labels, or: >>> 1. X hashes on the incoming packet, using its knowledge of the applicat= ion. >>> 2. X uses the result of the hash to choose the outgoing tunnel label TL >>> 3. X makes an entropy label from the hash. >>> 4. X pushes the following label stack: >>>=20 >>> Here are the benefits of associating the entropy label with tunnels: >>> a) there are far fewer tunneling protocols than applications. Standard= izing, implementing, testing, and interop-ing entropy labels just for tunne= ls rather than for all apps (and doing it again in the future for new apps)= is a huge win. >>>=20 >>> b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for = specific ingress-egress pairs), the ingress can meaningfully put/not put EL= s in the packet, based on the tunnel rather than the application. >>>=20 >>> c) app label processing on the egress is unaffected. The label stack t= hat the egress would get (assuming PHP) is . Preprocessing po= ps ELI+EL, leaving the processing of the AL the same as before. Processing= (if the entropy label is associated with the application) would m= ean touching the application label processing microcode for each app, some = of which (like VPLS) is fairly complex. >>>=20 >>> d) the "app" of carrying IP over MPLS is no longer a special case. [co= ntext: for IP over MPLS, as there is no app label, the label stack has to b= e , not .] >>>=20 >>> e) if multiple providers are involved in providing a service (CoC VPNs,= hierarchical tunnels, etc.), then each provider can autonomously insert an= entropy label for their tunnel. >>>=20 >>> The downside is that the label stack has one more label because the ELI= would be mandatory: rather than . >>=20 >> I am not concerned, in the least, of "burning" an extra 4-Bytes on the w= ire for an always present ELI: a) all links are already configured for Jumb= o frames and will not even notice an extra 4-Bytes; and, b) this is an extr= emely small price to pay (sorry for the pun), for the substantial and signi= ficant CapEx & OpEx savings for ensuring [very] good, fine-grained load-bal= ancing over LAG & ECMP paths in the Core. >>=20 >>=20 >>> So, the question: should we associate ELs with tunnels rather than with= applications (apart from PWs)? (if no, a short reason why would be helpfu= l.) >>=20 >> EL's with tunnels, please! >>=20 >> -shane >>=20 >>=20 >>> Thanks, >>> Kireeti. >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rmanur@broadcom.com Fri Apr 13 18:03:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2CF11E811C for ; Fri, 13 Apr 2012 18:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzH3dVWHeuo6 for ; Fri, 13 Apr 2012 18:03:09 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E921F863F for ; Fri, 13 Apr 2012 18:03:07 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 13 Apr 2012 18:12:38 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.17) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 13 Apr 2012 18:02:53 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 18:02:53 -0700 From: "Rajeev Manur" To: "Kireeti Kompella" Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0ZiHepB6t2loYdRx+hrEz0TIkrpAACI0QQAAmNQqAAEONjAAANxw9A//+6qICAAG5mIA== Date: Sat, 14 Apr 2012 01:02:52 +0000 Message-ID: <1E714095C88C9D408749A723A59CF6ED031975@SJEXCHMB12.corp.ad.broadcom.com> References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> <1E714095C88C9D408749A723A59CF6ED03182D@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.75.38] MIME-Version: 1.0 X-WSS-ID: 6396108C3E017633612-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 01:03:10 -0000 -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net]=20 Sent: Friday, April 13, 2012 5:22 PM To: Rajeev Manur Cc: shane@level3.net; mpls@ietf.org Subject: Re: MPLS entropy : clarification on the need for ELI On Apr 13, 2012, at 16:02, "Rajeev Manur" wrote: > Q2 : If yes, have we looked at other possible ways of working around the = problem. For example if such LSRs are capable of inserting at least 2 label= s, then we should be able to program such boxes to add second dummy label (= EL=3D"fixed value"). The problem is only partly "can it?". Even if it could, it doesn't at prese= nt. So, if you upgrade one LER to do ELs, no one else can talk to it until = they too are upgraded. All-or-nothing upgrade policies are not the best way= to make friends with network operators :-) [Rajeev] Agreed. Thanks for the clarification. It would be gr8 if we can ca= pture this reasoning of "incremental deployment" as the key reason for usin= g ELI label approach for LSPs. Kireeti From kireeti@juniper.net Sun Apr 15 21:50:39 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404E421F8703 for ; Sun, 15 Apr 2012 21:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMssHNTctNsC for ; Sun, 15 Apr 2012 21:50:38 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2785121F87B7 for ; Sun, 15 Apr 2012 21:50:38 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT4ulHCO3NmFfgSf37cdD2VDrtctP+Au1@postini.com; Sun, 15 Apr 2012 21:50:38 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Sun, 15 Apr 2012 21:50:20 -0700 From: Kireeti Kompella To: Rajeev Manur Date: Sun, 15 Apr 2012 21:50:25 -0700 Thread-Topic: MPLS entropy : clarification on the need for ELI Thread-Index: Ac0bjGyW+qgmyy6WRTy/ADyIQ0xn4A== Message-ID: <3D9D3C28-A6B4-44B2-A4B8-08A5757DAC54@juniper.net> References: <1E714095C88C9D408749A723A59CF6ED03177A@SJEXCHMB12.corp.ad.broadcom.com> <379B0F19-1BA1-483A-A29D-459B9E93279E@juniper.net> <1E714095C88C9D408749A723A59CF6ED03182D@SJEXCHMB12.corp.ad.broadcom.com> <1E714095C88C9D408749A723A59CF6ED031975@SJEXCHMB12.corp.ad.broadcom.com> In-Reply-To: <1E714095C88C9D408749A723A59CF6ED031975@SJEXCHMB12.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "shane@level3.net" Subject: Re: [mpls] MPLS entropy : clarification on the need for ELI X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 04:50:39 -0000 On Apr 13, 2012, at 18:03, "Rajeev Manur" wrote: > [Rajeev] Agreed. Thanks for the clarification. It would be gr8 if we can = capture this reasoning of "incremental deployment" as the key reason for us= ing ELI label approach for LSPs. It's not the key reason, but I'll capture it. Kireeti From iesg-secretary@ietf.org Mon Apr 16 09:49:52 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D424921F8655; Mon, 16 Apr 2012 09:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj-jsiSZX14U; Mon, 16 Apr 2012 09:49:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4411E8091; Mon, 16 Apr 2012 09:49:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120416164952.8368.57181.idtracker@ietfa.amsl.com> Date: Mon, 16 Apr 2012 09:49:52 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview' to Informational RFC (draft-ietf-mpls-tp-mib-management-overview-08.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:49:53 -0000 The IESG has approved the following document: - 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview' (draft-ietf-mpls-tp-mib-management-overview-08.txt) as an Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overview/ Technical Summary A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. Working Group Summary This document is a MPLS working group document, and part of the joint IETF - ITU.T MPLS-TP project. It has been reviewed in both organizations and there is a solid support for the document. Document Quality The document is well reviewed in the MPLS working group,the ITU-T and the MPLS-TP project. Personnel Loa Andersson (loa@pi.nu) is the document shepherd. Stewart Bryant (stbryant@cisco.com) is the Responsible Area Director? RFC Editor Note Section 6 OLD This section highlights new MIB modules that have been identified as being required for MPLS-TP. This section also provides an overview of the following: - the MPLS Object Identifier (OID) tree structure and the position of different MPLS related MIB modules on this tree; - the purpose of each of the MIB modules within the MIB documents, what it can be used for, and how it relates to the other MIB modules. NEW This section highlights new MIB modules that have been identified as being required for MPLS-TP. This section also provides an overview the purpose of each of the MIB modules within the MIB documents, what it can be used for, and how it relates to the other MIB modules. END -------------- OLD 6.1.1 Structure of the MPLS-TP MIB OID Tree The MPLS-TP MIB OID tree has the following structure. transmission -- RFC 2578 [RFC2578] | +- mplsStdMIB | +- Textual Conventions for MPLS-TP | +- Identifiers for MPLS-TP | +- LSR MIB Extensions for MPLS-TP | +- TE MIB Extensions for MPLS-TP Note that the MIB modules mentioned here are applicable for MPLS operations as well. Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. NEW 6.1.1 NEW MIB Modules for MPLS-TP Four new MIB modules are identified as follows: - Textual Conventions for MPLS-TP - Identifiers for MPLS-TP - LSR MIB Extensions for MPLS-TP - TE MIB Extensions for MPLS-TP Note that the MIB modules mentioned here are applicable for MPLS operations as well. END ----------- OLD 6.2.1 Structure of the PWE3 MIB OID Tree for MPLS-TP mib-2 -- RFC 2578 [RFC2578] | +-transmission | | | +- Pseudowire Extensions for MPLS-TP | +- Pseudowire MPLS Extensions for MPLS-TP | +- Pseudowire Textual Conventions for MPLS-TP Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. NEW 6.2.1 New MIB Modules for MPLS-TP Pseudowires Three new MIB modules are identified as follows: - Pseudowire Extensions for MPLS-TP - Pseudowire MPLS Extensions for MPLS-TP - Pseudowire Textual Conventions for MPLS-TP END --------------- OLD 6.3.1 Structure of the OAM MIB OID Tree for MPLS-TP mib-2 -- RFC 2578 [RFC2578] | +-transmission | +- BFD MIB module | +- OAM MIB module Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. NEW 6.3.1 New MIB Modules for OAM for MPLS-TP Two new MIB modules are identified as follows: - BFD MIB module - OAM MIB module END --------------- OLD 6.4.1 Structure of the MPLS Protection Switching and Recovery MIB OID Tree for MPLS-TP mib-2 -- RFC 2578 [RFC2578] | +-transmission | +- Linear Protection Switching MIB module | +- Ring Protection Switching MIB module | +- Mesh Protection Switching MIB module Note: The OIDs for MIB modules are yet to be assigned and managed by IANA. NEW 6.4.1 New MIB Modules for MPLS Protection Switching and Recovery Three new MIB modules are identified as follows: - Linear Protection Switching MIB module - Ring Protection Switching MIB module - Mesh Protection Switching MIB module END From lucy.yong@huawei.com Mon Apr 16 14:22:28 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5811E8091 for ; Mon, 16 Apr 2012 14:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfinAret7fSE for ; Mon, 16 Apr 2012 14:22:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4136C11E808A for ; Mon, 16 Apr 2012 14:22:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEY78231; Mon, 16 Apr 2012 17:22:27 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 14:20:28 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 16 Apr 2012 14:19:34 -0700 From: Lucy yong To: Alia Atlas , Shane Amante Thread-Topic: [mpls] entropy labels: associate with tunnels or apps? Thread-Index: AQHNGdQr6AQwHQKDaEWA/imUEbu6PJaZ7KmAgAQMecA= Date: Mon, 16 Apr 2012 21:20:24 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D3264A19A@dfweml505-mbx> References: <5AE06757-9968-4863-9AC1-6AB59830B09B@juniper.net> <9EC61509-064A-41D7-9A61-3DA6298A34C8@castlepoint.net> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.231] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] entropy labels: associate with tunnels or apps? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:22:28 -0000 I support the following: 1) use one reserved label for ELI 2) ELs associate with the tunnel layer Cheers, Lucy -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ali= a Atlas Sent: Friday, April 13, 2012 7:28 PM To: Shane Amante Cc: mpls@ietf.org Subject: Re: [mpls] entropy labels: associate with tunnels or apps? I agree with Shane & Kireeti - ELs at the tuunel-layer so it is solved once and done. Alia On Fri, Apr 13, 2012 at 8:18 PM, Shane Amante wrote= : > Kireeti, All, > > On Apr 12, 2012, at 2:20 PM, Kireeti Kompella wrote: >> This email is about: 2) should we associate the EL with tunnel labels or= with application labels? > > EL's with tunnel labels. =A0Definitely, tunnel labels. > > IMO, the most compelling reasons are (in addition to those you've already= provided below): > 1) =A0We solve for entropy labels _once_ at the tunnel-layer and we're do= ne. =A0IOW, entropy-labels should become a first-class citizen of the overa= ll MPLS architecture, which is goodness. > 2) =A0As an SP, testing entropy-labels at the tunnel layer in all future = HW/SW releases that gets pushed out to the network is _much_ more straightf= orward. =A0In summary, I would expect it to be much easier to _understand_ = and see when entropy-labels are being used at the tunnel layer vs. when & w= hy they are not. =A0IOW, when troubleshooting it will be much more noticeab= le that _ALL_ traffic is getting fine-grained load-balancing between a pair= of PE's, i.e.: at the tunnel-layer, compared to the machinations one may h= ave to go through to figure out if a _set_ of applications on a PE are _eac= h_ "doing the right thing" wrt signaling entropy-labels for themselves. > > One more thing below. > >> NOTE: this is for all applications OTHER THAN LDP pseudowires, where we = already have a solution. >> >> The philosophy here is that entropy labels are for improved ECMP; tunnel= s have ECMP; apps are point-to-point-ish. >> >> Here's how it would work: an egress LSR signals, along with a tunnel (LD= P or RSVP), its ability to process entropy labels. >> An ingress LSR X, when it resolves an application (e.g. L3VPN) to a tunn= el whose egress can process entropy labels, either decides not to insert en= tropy labels, or: >> 1. X hashes on the incoming packet, using its knowledge of the applicati= on. >> 2. X uses the result of the hash to choose the outgoing tunnel label TL >> 3. X makes an entropy label from the hash. >> 4. X pushes the following label stack: >> >> Here are the benefits of associating the entropy label with tunnels: >> a) there are far fewer tunneling protocols than applications. =A0Standar= dizing, implementing, testing, and interop-ing entropy labels just for tunn= els rather than for all apps (and doing it again in the future for new apps= ) is a huge win. >> >> b) if a provider has multiple tunnel types (LDP + tactical RSVP-TE for s= pecific ingress-egress pairs), the ingress can meaningfully put/not put ELs= in the packet, based on the tunnel rather than the application. >> >> c) app label processing on the egress is unaffected. =A0The label stack = that the egress would get (assuming PHP) is . =A0Preprocessing= pops ELI+EL, leaving the processing of the AL the same as before. =A0Proce= ssing (if the entropy label is associated with the application) wo= uld mean touching the application label processing microcode for each app, = some of which (like VPLS) is fairly complex. >> >> d) the "app" of carrying IP over MPLS is no longer a special case. =A0[c= ontext: for IP over MPLS, as there is no app label, the label stack has to = be , not .] >> >> e) if multiple providers are involved in providing a service (CoC VPNs, = hierarchical tunnels, etc.), then each provider can autonomously insert an = entropy label for their tunnel. >> >> The downside is that the label stack has one more label because the ELI = would be mandatory: rather than . > > I am not concerned, in the least, of "burning" an extra 4-Bytes on the wi= re for an always present ELI: a) all links are already configured for Jumbo= frames and will not even notice an extra 4-Bytes; and, b) this is an extre= mely small price to pay (sorry for the pun), for the substantial and signif= icant CapEx & OpEx savings for ensuring [very] good, fine-grained load-bala= ncing over LAG & ECMP paths in the Core. > > >> So, the question: should we associate ELs with tunnels rather than with = applications (apart from PWs)? =A0(if no, a short reason why would be helpf= ul.) > > EL's with tunnels, please! > > -shane > > >> Thanks, >> Kireeti. >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Tue Apr 17 01:20:24 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC44C21F8585; Tue, 17 Apr 2012 01:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cac9Z0dC4Q6O; Tue, 17 Apr 2012 01:20:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C37E21F8562; Tue, 17 Apr 2012 01:20:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417082014.24008.45140.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 01:20:14 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-oam-analysis-09.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 08:20:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : An Overview of the OAM Tool Set for MPLS based Transport= Networks Author(s) : Nurit Sprecher Luyuan Fang Filename : draft-ietf-mpls-tp-oam-analysis-09.txt Pages : 22 Date : 2012-04-17 This document provides an overview of the OAM toolset for MPLS based Transport Networks (MPLS-TP). The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-analysis-09.txt From michelg@upperside.fr Tue Apr 17 05:02:23 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618F21F8581 for ; Tue, 17 Apr 2012 05:02:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPbDxY2waT96 for ; Tue, 17 Apr 2012 05:02:19 -0700 (PDT) Received: from smtp06.msg.oleane.net (smtp06.msg.oleane.net [62.161.4.6]) by ietfa.amsl.com (Postfix) with ESMTP id 55DAC21F8592 for ; Tue, 17 Apr 2012 05:02:17 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp06.msg.oleane.net (MSA) with ESMTP id q3HC2DqC004432 for ; Tue, 17 Apr 2012 14:02:14 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Tue, 17 Apr 2012 14:02:06 +0200 Message-ID: <001f01cd1c91$ed5eefb0$c81ccf10$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD1CA2.B0EACCF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0ckdjVd7HxTDIJQMuCJWzS+yTZSQ== Content-Language: fr X-PMX-Spam: Probability=9% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.17.114816 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] SDN Workshop and Carrier Cloud Summit 2012 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 12:02:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CD1CA2.B0EACCF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit What are the architectural choices ? What could be the role of SDN and OpenFlow ? What are the service strategies of service providers and cloud providers ? Which networking solutions are proposed ? During the Carrier Cloud Summit and SDN Workshop which will be held in Novotel Paris CDG from 19 to 21 June, 2012, project leaders, manufacturers and service developers will address these aspects in detail through up to date contributions. More information: http://www.uppersideconferences.com/ ------=_NextPart_000_0020_01CD1CA2.B0EACCF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What are the architectural choices ?
What could be the role of = SDN and OpenFlow ?
What are = the service strategies of service providers and cloud = providers ?
Which networking solutions are = proposed ?

During the Carrier Cloud Summit and SDN Workshop which will be = held in Novotel Paris CDG from = 19 to 21 June, 2012, project leaders, manufacturers and service developers will = address these aspects in detail through up to date = contributions.

More information: http://www.uppersideconferences.com/

 

------=_NextPart_000_0020_01CD1CA2.B0EACCF0-- From loa@pi.nu Wed Apr 18 05:17:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B29521F8453 for ; Wed, 18 Apr 2012 05:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzkcsNDkxcWg for ; Wed, 18 Apr 2012 05:17:04 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 0D18421F843F for ; Wed, 18 Apr 2012 05:17:03 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 750172A8002 for ; Wed, 18 Apr 2012 14:17:02 +0200 (CEST) Message-ID: <4F8EB0BD.2050303@pi.nu> Date: Wed, 18 Apr 2012 14:17:01 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Implementations of draft-ietf-mpls-ldp-gtsm-05 ?? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 12:17:04 -0000 Working Group, the working group chairs are preparing a request for publication of draft-ietf-mpls-ldp-gtsm-05. We will need to if there are any implementations of this draft. If you have such an implementation please send information to the working group mailing list, or directly to the wg chairs. /Loa for the mpls wg co-chairs. -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Wed Apr 18 05:46:30 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5885221F8469 for ; Wed, 18 Apr 2012 05:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNC7dZYz1N+e for ; Wed, 18 Apr 2012 05:46:29 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id C0EFE21F8593 for ; Wed, 18 Apr 2012 05:46:29 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id DF2E02A8002 for ; Wed, 18 Apr 2012 14:46:28 +0200 (CEST) Message-ID: <4F8EB7A4.3080003@pi.nu> Date: Wed, 18 Apr 2012 14:46:28 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: mpls@ietf.org References: <4F8EB0BD.2050303@pi.nu> In-Reply-To: <4F8EB0BD.2050303@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] Implementations of draft-ietf-mpls-ldp-gtsm-05 ?? X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 12:46:30 -0000 Folks, I intended the dead line for this to be April 28, but the sooner the better. /Loa On 2012-04-18 14:17, Loa Andersson wrote: > Working Group, > > the working group chairs are preparing a request for publication of > draft-ietf-mpls-ldp-gtsm-05. We will need to if there are any > implementations of this draft. > > If you have such an implementation please send information to the > working group mailing list, or directly to the wg chairs. > > /Loa > for the mpls wg co-chairs. > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From martin.vigoureux@alcatel-lucent.com Wed Apr 18 07:34:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69A21F85C2 for ; Wed, 18 Apr 2012 07:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.949 X-Spam-Level: X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnMV5QuSWkal for ; Wed, 18 Apr 2012 07:34:16 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id F3F8821F85D5 for ; Wed, 18 Apr 2012 07:34:15 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3IEYC0J007842 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 Apr 2012 16:34:13 +0200 Received: from [172.27.205.177] (135.120.57.7) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Apr 2012 16:33:54 +0200 Message-ID: <4F8ED0D2.50500@alcatel-lucent.com> Date: Wed, 18 Apr 2012 16:33:54 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "MPLS @ IETF" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: [mpls] IETF 83 - Minutes of the MPLS WG Sessions X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:34:20 -0000 all, please find the minutes following the link http://www.ietf.org/proceedings/83/minutes/minutes-83-mpls.txt Let me know of any modification that you think should be brought to these. martin From muly_i@rad.com Thu Apr 19 06:31:09 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7501421F861C for ; Thu, 19 Apr 2012 06:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BqwGcIG1+4F for ; Thu, 19 Apr 2012 06:31:08 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id EA34821F861B for ; Thu, 19 Apr 2012 06:31:05 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 19 Apr 2012 16:15:40 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Thu, 19 Apr 2012 16:30:55 +0300 From: Muly Ilan To: "mpls@ietf.org" Thread-Topic: Comments to draft-ietf-mpls-tp-oam-analysis-09 Thread-Index: Ac0eMKPxsfDyw7x4SSy15DbQduBQ9g== Date: Thu, 19 Apr 2012 13:30:54 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87041A6C97@EXRAD5.ad.rad.co.il> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC87041A6C97EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020209.4F901396.00AC,ss=1,fgs=0 Subject: [mpls] Comments to draft-ietf-mpls-tp-oam-analysis-09 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:31:09 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87041A6C97EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Among other documents draft-ietf-mpls-tp-oam-analysis-09 references RFC6427= and RFC6435. I have noticed a few discrepancies: 1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback = is a management command. 2. Table 2, second row - LSP Ping is not related to Lock Instruct or = loopback command. 3. Table 2, third row - Lock Instruct is not indicated by a flag in A= IS message and is not discussed in RFC6427. 4. Section 5.2, third paragraph - need rewriting, per RFC6435 there's= no loopback request message nor loopback response message. Regards, Muly Ilan --_000_32CB7A1F0806AB4688CE3F22C29DAC87041A6C97EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Among other documents draft-ietf-mpls-tp-oam-analysi= s-09 references RFC6427 and RFC6435.

I have noticed a few discrepancies:

1.     &= nbsp; Table 2, second row –= ; only Lock Instruct is G-Ach based. Loopback is a management command.=

2.     &= nbsp; Table 2, second row –= ; LSP Ping is not related to Lock Instruct or loopback command.<= /p>

3.     &= nbsp; Table 2, third row –= Lock Instruct is not indicated by a flag in AIS message and is not discuss= ed in RFC6427.

4.     &= nbsp; Section 5.2, third paragra= ph – need rewriting, per RFC6435 there’s no loopback request me= ssage nor loopback response message.

 

 

Regards,

 

Muly Ilan

 

--_000_32CB7A1F0806AB4688CE3F22C29DAC87041A6C97EXRAD5adradcoil_-- From danfrost@cisco.com Fri Apr 20 00:43:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05D21F86EA for ; Fri, 20 Apr 2012 00:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct7+DhZ+4VeH for ; Fri, 20 Apr 2012 00:43:03 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7EB21F86E5 for ; Fri, 20 Apr 2012 00:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=danfrost@cisco.com; l=301; q=dns/txt; s=iport; t=1334907783; x=1336117383; h=date:from:to:subject:message-id:mime-version; bh=GJjjdMoPRZbbFSyCHUb25t8pYTp1ad3diDTOD74dKNc=; b=DqZ5jq1uuPNyrYmG9uWoRG64D4uxf7AqNaq8OOxDm4rxEU+VqhwUKjn/ XQd1pAmqBf6PqfdpYhhoIAi4AiP2ak/sLNq8arqQyBIiRSyxIdBQLmPGd vcMKE2C+ChPLwm3zIoOW5tGya9F20YozQoLY4/TCOpbaMFb+XmD6Mrk9k o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAAkTkU+tJXG9/2dsb2JhbABDsUGBB4IiASeBNGUZh20LmSGBKKAyjUKCQmMElXgBjlSBaYJo X-IronPort-AV: E=Sophos;i="4.75,451,1330905600"; d="scan'208";a="76301022" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 20 Apr 2012 07:43:01 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3K7h1c3025734 for ; Fri, 20 Apr 2012 07:43:01 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id q3K7h01L022415 for ; Fri, 20 Apr 2012 03:43:00 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id q3K7h04e022414 for mpls@ietf.org; Fri, 20 Apr 2012 08:43:00 +0100 Date: Fri, 20 Apr 2012 08:43:00 +0100 From: Dan Frost To: mpls@ietf.org Message-ID: <20120420074300.GA22231@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [mpls] Ethernet multicast DA allocation for p2p MPLS-TP X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 07:43:04 -0000 Please note that IANA has allocated an Ethernet multicast MAC address for MPLS-TP use over point-to-point Ethernet links, per Section 6.1 of draft-ietf-mpls-tp-ethernet-addressing-00. The allocated address is 01-00-5E-90-00-00 as found in: http://www.iana.org/assignments/ethernet-numbers -d From adrian@olddog.co.uk Mon Apr 23 07:32:01 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3721F8630 for ; Mon, 23 Apr 2012 07:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0va0rNBUOvXy for ; Mon, 23 Apr 2012 07:32:00 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 9640921F865D for ; Mon, 23 Apr 2012 07:31:59 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3NEVv2R020829; Mon, 23 Apr 2012 15:31:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3NEVp92020784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Apr 2012 15:31:55 +0100 From: "Adrian Farrel" To: "'Muly Ilan'" , References: <32CB7A1F0806AB4688CE3F22C29DAC87041A6C97@EXRAD5.ad.rad.co.il> In-Reply-To: <32CB7A1F0806AB4688CE3F22C29DAC87041A6C97@EXRAD5.ad.rad.co.il> Date: Mon, 23 Apr 2012 15:31:51 +0100 Message-ID: <000701cd215d$d4cc0cf0$7e6426d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01CD2166.36968F70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIaggk4z33s5saBWHbeOEWq8xxISJYNtdMA Content-Language: en-gb Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-oam-analysis-09 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:32:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01CD2166.36968F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Muly, Your comments come a bit late, but I will enter them as Comments into the IESG evaluation so they should get picked up as editorial fixes. Thanks, Adrian From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Muly Ilan Sent: 19 April 2012 14:31 To: mpls@ietf.org Subject: [mpls] Comments to draft-ietf-mpls-tp-oam-analysis-09 Hi all, Among other documents draft-ietf-mpls-tp-oam-analysis-09 references RFC6427 and RFC6435. I have noticed a few discrepancies: 1. Table 2, second row - only Lock Instruct is G-Ach based. Loopback is a management command. 2. Table 2, second row - LSP Ping is not related to Lock Instruct or loopback command. 3. Table 2, third row - Lock Instruct is not indicated by a flag in AIS message and is not discussed in RFC6427. 4. Section 5.2, third paragraph - need rewriting, per RFC6435 there's no loopback request message nor loopback response message. Regards, Muly Ilan ------=_NextPart_000_0008_01CD2166.36968F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Muly,

 

Your comments come a = bit late, but I will enter them as Comments into the IESG evaluation so = they should get picked up as editorial fixes.

 

Thanks,

Adrian

 

From: = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Muly Ilan
Sent: 19 April 2012 14:31
To: = mpls@ietf.org
Subject: [mpls] Comments to = draft-ietf-mpls-tp-oam-analysis-09

 

Hi = all,

 

Among other documents = draft-ietf-mpls-tp-oam-analysis-09 references RFC6427 and = RFC6435.

I have noticed a few = discrepancies:

1.       = Table 2, second row – only Lock = Instruct is G-Ach based. Loopback is a management = command.

2.       = Table 2, second row – LSP Ping = is not related to Lock Instruct or loopback = command.

3.       = Table 2, third row – Lock = Instruct is not indicated by a flag in AIS message and is not discussed = in RFC6427.

4.       = Section 5.2, third paragraph – = need rewriting, per RFC6435 there’s no loopback request message = nor loopback response message.

 

 

Regards,

 

Muly Ilan

 

------=_NextPart_000_0008_01CD2166.36968F70-- From balavenkata@gmail.com Thu Apr 12 01:16:10 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3321F8582 for ; Thu, 12 Apr 2012 01:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TekJNkDb9SWt for ; Thu, 12 Apr 2012 01:16:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1124C21F857A for ; Thu, 12 Apr 2012 01:16:08 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1401914vcb.31 for ; Thu, 12 Apr 2012 01:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=LwiSZxGhztB9dX2HzL2fB/yYZGUsKuA5tx5IzATldpw=; b=Es9AeHo5EeTupGm1cyHJAmYi4dyKyc4UqfwI/inVFe1rQbwvsr0pyRIqeHeyBEJW7p myHhPdkQBLqUWbKg1zmFJoBAGQ31MOIe+lackEejnUpak9RQNLHqmrVM2V2BXOVjjQ85 WXnUg2YSUbdUZTS6VUk2k2dLnVPm7j7rwAn0slOKc48neSvE0dK3juinHGveVzx+C0YT VFLmw8mMfYpE4hVmL9FqTjEWYkDhomwQYcLqBorAYF7w9IlFr12bfZprvKefAnx9Isd/ WYgleOdhdL4hL8xmpSzvjQL6WC3KnFsNVy1yMuLV/ietyTA1Yjaf05JLXRcv+fzEY77B uc6g== MIME-Version: 1.0 Received: by 10.52.94.233 with SMTP id df9mr612193vdb.119.1334218568452; Thu, 12 Apr 2012 01:16:08 -0700 (PDT) Received: by 10.220.201.75 with HTTP; Thu, 12 Apr 2012 01:16:08 -0700 (PDT) Date: Thu, 12 Apr 2012 13:46:08 +0530 Message-ID: From: Bala Subrahmanyam Venkata To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 24 Apr 2012 14:21:09 -0700 Subject: [mpls] A question on draft-vkst-bfd-mpls-mib-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 08:51:43 -0000 Hello- This is regarging the BFD MIB for MPLS-TP posted here: http://www.ietf.org/mail-archive/web/i-d-announce/current/msg42230.html I have a question about=A0bfdMplsSessMode column proposed. It says bfdMplsSessMode OBJECT-TYPE SYNTAX INTEGER { cc(1), cv(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies whether the BFD session is running in Continuity Check(CC) or the Connectivity Verification(CV) mode." REFERENCE "1.Proactive Connectivity Verification, Continuity Check and Remote Defect Indication for MPLS Transport Profile, draft-ietf-mpls-tp-cc-cv-rdi-06" DEFVAL { cc } ::=3D { bfdMplsSessEntry 2 } What about the cases where=A0 =A0the CC and CV messages are sent over the same session ? Is it expected that two entries exist in the bfdMplsSessTable - one for CC and another for CV ? I'm referring to the first line in section 3.2 of RFC 6428: "The combined CC, CV, and RDI functionality for MPLS-TP is achieved by multiplexing CC and CV PDUs within a single BFD session." Btw, replace the 'draft' reference with 'RFC 6428' in the MIB. Thanks ! /bala From venkatflex@gmail.com Tue Apr 24 16:34:51 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A154C21F85D8 for ; Tue, 24 Apr 2012 16:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5+98JCabQtR for ; Tue, 24 Apr 2012 16:34:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C86C21F84B3 for ; Tue, 24 Apr 2012 16:34:50 -0700 (PDT) Received: by lagj5 with SMTP id j5so1028656lag.31 for ; Tue, 24 Apr 2012 16:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1C+keSXN8/OPdjSIgArITnNav0y1KtZRRBOe7BPx29U=; b=I0uEiMlv8DK8dzChJ++TJXFxtl6gfJSWdk194YkGj0zFm0aXwo5JqCfHpiLIf5S1Ez 3+TImYbIxa3d5IgU6+QP9fqtojfGJadgZ7VJH+t4FgFam1hkOUQrbATcvvkk6XKTB9/7 YbzqC1ebSNCvpNwPPUQqaKgFU/aZB6vmF0z6rd9M6T92lV8MNtjU4pnBLO42FMaym7E2 1CqnOXPwvt/uXosJ2bhCJn+667l3Rb614VtE7v2OIiX99J3PfoQSfoG0UnBG+6KfXH6S nsN+guH6pt/ryk5+9QDRi5tCZ9cAOG4HshJKDa5+vbrQbuKPHdN4LpezG1UYfxfmRm8u Xcdg== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr464590lab.0.1335310489171; Tue, 24 Apr 2012 16:34:49 -0700 (PDT) Received: by 10.112.33.233 with HTTP; Tue, 24 Apr 2012 16:34:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Apr 2012 16:34:49 -0700 Message-ID: From: venkatesan mahalingam To: Bala Subrahmanyam Venkata , mpls Content-Type: multipart/alternative; boundary=f46d042dfea95f374204be75333a Cc: Thomas Nadeau , Sam Aldrin Subject: Re: [mpls] A question on draft-vkst-bfd-mpls-mib-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 23:34:51 -0000 --f46d042dfea95f374204be75333a Content-Type: text/plain; charset=ISO-8859-1 Bala, Sorry for the delayed response. Please see in-line. Thanks, Venkat. On Thu, Apr 12, 2012 at 1:16 AM, Bala Subrahmanyam Venkata < balavenkata@gmail.com> wrote: > Hello- > > This is regarging the BFD MIB for MPLS-TP posted here: > > http://www.ietf.org/mail-archive/web/i-d-announce/current/msg42230.html > > I have a question about bfdMplsSessMode column proposed. It says > > bfdMplsSessMode OBJECT-TYPE > SYNTAX INTEGER { > cc(1), > cv(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object specifies whether the BFD session is running > in Continuity Check(CC) or the Connectivity > Verification(CV) mode." > REFERENCE > "1.Proactive Connectivity Verification, Continuity Check > and Remote Defect Indication for MPLS Transport > Profile, draft-ietf-mpls-tp-cc-cv-rdi-06" > DEFVAL { cc } > > ::= { bfdMplsSessEntry 2 } > > > What about the cases where the CC and CV messages are sent over the > same session ? Is it expected that two entries exist in the > bfdMplsSessTable - one for CC and another for CV ? I'm referring to > the first line in section 3.2 of RFC 6428: "The combined CC, CV, and > RDI functionality for MPLS-TP is achieved by multiplexing CC and CV > PDUs within a single BFD session." > [VM] bfdMplsSessMode can have the option cc-cv (3) for multiplexing CC & > CV PDUs within a single BFD session and we will add/modify the necessary MIB objects if required > to accommodate this requirement completely. > Btw, replace the 'draft' reference with 'RFC 6428' in the MIB. > [VM] Thanks. We'll correct it in the next version. > > Thanks ! > > /bala > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --f46d042dfea95f374204be75333a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Bala,

=
Sorry for the delayed response. Please see in-li= ne.

Th= anks,
Venkat.

On Thu= , Apr 12, 2012 at 1:16 AM, Bala Subrahmanyam Venkata <= balavenkata@gmai= l.com> wrote:
Hello-

This is regarging the BFD MIB for MPLS-TP posted here:

http://www.ietf.org/mail-archive/web/i-d-announc= e/current/msg42230.html

I have a question about=A0bfdMplsSessMode column proposed. It says

bfdMplsSessMode =A0OBJECT-TYPE
=A0 =A0 =A0 =A0 =A0 SYNTAX =A0 =A0 =A0INTEGER {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cc(1),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 cv(2)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 MAX-ACCESS =A0read-create
=A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0current
=A0 =A0 =A0 =A0 =A0 DESCRIPTION
=A0 =A0 =A0 =A0 =A0 =A0 "This object specifies whether the BFD sessio= n is running
=A0 =A0 =A0 =A0 =A0 =A0 =A0in Continuity Check(CC) or the Connectivity
=A0 =A0 =A0 =A0 =A0 =A0 =A0Verification(CV) mode."
=A0 =A0 =A0 =A0 =A0 REFERENCE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 "1.Proactive Connectivity Verification, C= ontinuity Check
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and Remote Defect Indication for MPLS T= ransport
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Profile, draft-ietf-mpls-tp-cc-cv-rdi-0= 6"
=A0 =A0 =A0 =A0 =A0 DEFVAL { cc }

=A0 =A0 =A0 ::=3D { bfdMplsSessEntry 2 }


What about the cases where=A0 =A0the CC and CV messages are sent over the same session ? Is it expected that two entries exist in the
bfdMplsSessTable - one for CC and another for CV ? I'm referring to
the first line in section 3.2 of RFC 6428: "The combined CC, CV, and RDI functionality for MPLS-TP is achieved by multiplexing CC and CV
PDUs within a single BFD session."
[VM]=A0bfdMplsSessMode can have the option cc-cv (3) for multiplexing CC &a= mp; CV PDUs within a single BFD session
and we will add/modify the necessary MIB objects if required to=A0accommoda= te=A0this requirement completely.
=A0
Btw, replace the 'draft' reference with 'RFC 6428' in the M= IB.
[VM] Thanks. We'll correct it in the next version.

Thanks !

/bala
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--f46d042dfea95f374204be75333a-- From francesco.fondelli@gmail.com Wed Apr 25 12:38:16 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC3F21F88E5 for ; Wed, 25 Apr 2012 12:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0dXwoozCFkr for ; Wed, 25 Apr 2012 12:38:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8480221F88E3 for ; Wed, 25 Apr 2012 12:38:15 -0700 (PDT) Received: by yhkk25 with SMTP id k25so513992yhk.31 for ; Wed, 25 Apr 2012 12:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zdMCoSinot/jZibKud4H7rt4HfKRyuhxKCVtCuw2egs=; b=RAKw+3F1EM4gyepp/B75861EG4XTbk0aDb3VSfHVl7R4bMa7cmZNBeR2sAlEcGUepZ QwL5EyLD21vynINhwT0Ph+IYP4M7PFe6zahE7u6RNmPqeqpBmXfwyjoHTqQ+b2el+TmZ 1UNu2wlGObNOm1+9oMQ+jOC46Y/iU2CEEAYGb3i+UtDNg/htplTv6cyCwdi1W6o5/D09 Fbhtsu86GiT+lC0THtp64FJvBjFeQooWTkuJbgG4+hOLYHP0BXh/yZKVltxF41d2oLb6 gNwVLfSUf1tsJAH13IN0NxyfSYFAxXsIL+IxLeg7NOAc7KFDvuyy1ojtlvovZAY3eWAS DLIw== MIME-Version: 1.0 Received: by 10.236.187.68 with SMTP id x44mr3667882yhm.129.1335382695097; Wed, 25 Apr 2012 12:38:15 -0700 (PDT) Received: by 10.236.46.233 with HTTP; Wed, 25 Apr 2012 12:38:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 25 Apr 2012 21:38:15 +0200 Message-ID: From: Francesco Fondelli To: venkatesan mahalingam Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mpls , Sam Aldrin , Bala Subrahmanyam Venkata , Thomas Nadeau Subject: Re: [mpls] A question on draft-vkst-bfd-mpls-mib-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:38:16 -0000 Hi, On Wed, Apr 25, 2012 at 1:34 AM, venkatesan mahalingam wrote: > Bala, > > Sorry for the delayed response. Please see in-line. [cut] >> bfdMplsSessMode =C2=A0OBJECT-TYPE >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SYNTAX =C2=A0 =C2=A0 =C2=A0INTEGER { >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 cc(1), >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 cv(2) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 } [cut] >> [VM]=C2=A0bfdMplsSessMode can have the option cc-cv (3) for multiplexing= CC & >> CV PDUs within a single BFD session I think cv(2) mode does not exist. As far as I understand RFC 6428 we have plain cc(1) or cc-cv(3). hope this helps ciao FF From liu.guoman@zte.com.cn Thu Apr 26 01:33:38 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F86221F867B for ; Thu, 26 Apr 2012 01:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.435 X-Spam-Level: X-Spam-Status: No, score=-94.435 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyardv-znqeY for ; Thu, 26 Apr 2012 01:33:37 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A937F21F865C for ; Thu, 26 Apr 2012 01:33:36 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 28620806486374; Thu, 26 Apr 2012 15:53:09 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 70266.806486374; Thu, 26 Apr 2012 16:33:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q3Q8XGfO099144 for ; Thu, 26 Apr 2012 16:33:16 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <20120426081029.9132.83935.idtracker@ietfa.amsl.com> To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Thu, 26 Apr 2012 16:33:18 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-04-26 16:33:19, Serialize complete at 2012-04-26 16:33:19 Content-Type: multipart/alternative; boundary="=_alternative 002F0C76482579EC_=" X-MAIL: mse02.zte.com.cn q3Q8XGfO099144 Subject: Re: [mpls] New Version Notification for draft-liu-mpls-tp-interconnected-ring-protection-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:33:38 -0000 This is a multipart message in MIME format. --=_alternative 002F0C76482579EC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksIGFsbA0KaSBqdXN0IHVwZGF0ZSB0aGlzIGRyYWZ0IGFjY29yZGluZyB0byBjb21tZW50cyBh bmQgcXVlc3Rpb25zIGZyb20gc29tZSANCmV4cGVydHMuDQp0aGlzIHZlcnNpb24gbWFpbmx5IGFk ZCBhIHByb3RlY3Rpb24gbWVjaG5pc20gZGVzY3JpYmVzIGFuZCBkZWxldGUgdGhlIA0Kc2VjdGlv biBvZg0KcmVjb3ZlcnkgbWVjaGFuaXNtIGZvciBzaW5nbGUtbm9kZSBpbnRlcmNvbm5lY3Rpb24g c2NlbmFyaW8uDQptYXliZSB0aGUgcmVjb3ZlcnkgbWVjaGFuaXNtIG5vdCBjb21wbGV0ZSwgd2Vs Y29tZSBhbGwgZXhwZXJ0cyB0byBwcm92aWRlIA0KZ29vZA0Kc29sdXRpb24gYW5kIGNvbW1lbnRz IGZvciB0aGlzIGRyYWZ0Lg0KdGhhbmsgeW91IHZlcnkgbXVjaCENCg0KQi5SLg0KbGl1DQoNCg0K DQoNCg0KDQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyANCjIwMTItMDQtMjYgMTY6MTANCg0K ytW8/sjLDQpsaXUuZ3VvbWFuQHp0ZS5jb20uY24NCrOty80NCnd5YWFjb3ZAZ21haWwuY29tDQrW 98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KZHJhZnQtbGl1LW1wbHMtdHAtaW50 ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uLTAxLnR4dA0KDQoNCg0KDQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIA0KZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1wcm90 ZWN0aW9uLTAxLnR4dCBoYXMgYmVlbiANCnN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWlRFIENv cnBvcmF0aW9uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgDQpyZXBvc2l0b3J5Lg0KDQpGaWxlbmFt ZTogICAgICAgICAgICAgICAgIGRyYWZ0LWxpdS1tcGxzLXRwLWludGVyY29ubmVjdGVkLXJpbmct cHJvdGVjdGlvbg0KUmV2aXNpb246ICAgICAgICAgICAgICAgICAwMQ0KVGl0bGU6ICAgICAgICAg ICAgICAgICAgICAgICAgICAgIE1QTFMtVFAgcHJvdGVjdGlvbiBmb3IgaW50ZXJjb25uZWN0ZWQg DQpyaW5ncw0KQ3JlYXRpb24gZGF0ZTogICAgICAgICAgICAyMDEyLTA0LTI2DQpXRyBJRDogICAg ICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDExDQoNCkFic3RyYWN0Og0KICAgQWNjb3JkaW5nIHRvIHRoZSByaW5nIHByb3RlY3Rp b24gUmVxdWlyZW1lbnRzIGluIFJGQyA1NjU0LA0KICAgUmVxdWlyZW1lbnQgOTMgOiBXaGVuIGEg bmV0d29yayBpcyBjb25zdHJ1Y3RlZCBmcm9tIGludGVyY29ubmVjdGVkDQogICByaW5ncywgTVBM Uy1UUCBNVVNUIHN1cHBvcnQgcmVjb3ZlcnkgbWVjaGFuaXNtcyB0aGF0IHByb3RlY3QgdXNlcg0K ICAgZGF0YSB0aGF0IHRyYXZlcnNlcyBtb3JlIHRoYW4gb25lIHJpbmcuICBUaGlzIGluY2x1ZGVz IHRoZQ0KICAgcG9zc2liaWxpdHkgb2YgZmFpbHVyZSBvZiB0aGUgcmluZy1pbnRlcmNvbm5lY3Qg bm9kZXMgYW5kIGxpbmtzLHNvDQogICB0aGlzIGRvY3VtZW50IHdpbGwgZGVzY3JpYmxlIGFsbCBr aW5kcyBvZiBpbnRlcmNvbm5lY3RlZCByaW5nDQogICBTY2VuYXJpb3MgYW5kIHNldmVyYWwgcHJv dGVjdGlvbiBzb2x1dGlvbnMgZm9yIHJlY292ZXJ5IHRoZSBmYWlsdXJlDQogICBvZiB0aGUgcmlu Zy1pbnRlcmNvbm5lY3Qgbm9kZXMgYW5kIExpbmtzLiAuDQoNCg0KICAgVGhpcyBkb2N1bWVudCBp cyBhIHByb2R1Y3Qgb2YgYSBqb2ludCBJbnRlcm5ldCBUYXNrIEZvcmNlKElFVEYpIC8NCiAgIElu dGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb25zIFVuaW9uIFRlbGVjb21tdW5pY2F0aW9ucw0K ICAgU3RhbmRhcmRpemF0aW9uIFNlY3RvciAoSVRVLVQpIGVmZm9ydCB0byBpbmNsdWRlIGFuIE1Q TFMgVHJhbnNwb3J0DQogICBQcm9maWxlIHdpdGhpbiB0aGUgSUVURiBNUExTIGFuZCBQV0UzIGFy Y2hpdGVjdHVyZXMgdG8gc3VwcG9ydCB0aGUNCiAgIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25h bGl0aWVzIG9mIGEgcGFja2V0IHRyYW5zcG9ydCBuZXR3b3JrIGFzDQogICBkZWZpbmVkIGJ5IHRo ZSBJVFUtVC4NCg0KICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 002F0C76482579EC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLCBhbGw8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmkganVzdCB1cGRhdGUgdGhpcyBkcmFmdCBh Y2NvcmRpbmcgdG8NCmNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgZnJvbSBzb21lIGV4cGVydHMuPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGlzIHZlcnNpb24gbWFp bmx5IGFkZCBhIHByb3RlY3Rpb24NCm1lY2huaXNtIGRlc2NyaWJlcyBhbmQgZGVsZXRlIHRoZSBz ZWN0aW9uIG9mPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5yZWNv dmVyeSBtZWNoYW5pc20gZm9yIHNpbmdsZS1ub2RlIGludGVyY29ubmVjdGlvbg0Kc2NlbmFyaW8u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5tYXliZSB0aGUgcmVj b3ZlcnkgbWVjaGFuaXNtIG5vdCBjb21wbGV0ZSwNCndlbGNvbWUgYWxsIGV4cGVydHMgdG8gcHJv dmlkZSBnb29kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5zb2x1 dGlvbiBhbmQgY29tbWVudHMgZm9yIHRoaXMgZHJhZnQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFuayB5b3UgdmVyeSBtdWNoITwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Qi5SLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+bGl1PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0K PHRkPg0KPGRpdiBhbGlnbj1jZW50ZXI+PC9kaXY+DQo8dGQ+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5pbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMi0wNC0yNiAxNjoxMDwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5saXUuZ3VvbWFuQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi Pnd5YWFjb3ZAZ21haWwuY29tPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5OZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1saXUtbXBscy10cC1p bnRlcmNvbm5lY3RlZC1yaW5nLXByb3RlY3Rpb24tMDEudHh0PC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5BIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uLTAxLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBaVEUgQ29ycG9yYXRpb24gYW5k IHBvc3RlZCB0byB0aGUgSUVURg0KcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uPGJyPg0K UmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOzAxPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpNUExTLVRQIHByb3RlY3Rpb24g Zm9yIGludGVyY29ubmVjdGVkIHJpbmdzPGJyPg0KQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MjAxMi0w NC0yNjxicj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVy IG9mIHBhZ2VzOiAxMTxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiAmbmJzcDsgQWNjb3JkaW5n IHRvIHRoZSByaW5nIHByb3RlY3Rpb24gUmVxdWlyZW1lbnRzIGluIFJGQyA1NjU0LDxicj4NCiAm bmJzcDsgUmVxdWlyZW1lbnQgOTMgOiBXaGVuIGEgbmV0d29yayBpcyBjb25zdHJ1Y3RlZCBmcm9t IGludGVyY29ubmVjdGVkPGJyPg0KICZuYnNwOyByaW5ncywgTVBMUy1UUCBNVVNUIHN1cHBvcnQg cmVjb3ZlcnkgbWVjaGFuaXNtcyB0aGF0IHByb3RlY3QgdXNlcjxicj4NCiAmbmJzcDsgZGF0YSB0 aGF0IHRyYXZlcnNlcyBtb3JlIHRoYW4gb25lIHJpbmcuICZuYnNwO1RoaXMgaW5jbHVkZXMgdGhl PGJyPg0KICZuYnNwOyBwb3NzaWJpbGl0eSBvZiBmYWlsdXJlIG9mIHRoZSByaW5nLWludGVyY29u bmVjdCBub2RlcyBhbmQgbGlua3Msc288YnI+DQogJm5ic3A7IHRoaXMgZG9jdW1lbnQgd2lsbCBk ZXNjcmlibGUgYWxsIGtpbmRzIG9mIGludGVyY29ubmVjdGVkIHJpbmc8YnI+DQogJm5ic3A7IFNj ZW5hcmlvcyBhbmQgc2V2ZXJhbCBwcm90ZWN0aW9uIHNvbHV0aW9ucyBmb3IgcmVjb3ZlcnkgdGhl IGZhaWx1cmU8YnI+DQogJm5ic3A7IG9mIHRoZSByaW5nLWludGVyY29ubmVjdCBub2RlcyBhbmQg TGlua3MuIC48YnI+DQo8YnI+DQo8YnI+DQogJm5ic3A7IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9k dWN0IG9mIGEgam9pbnQgSW50ZXJuZXQgVGFzayBGb3JjZShJRVRGKQ0KLzxicj4NCiAmbmJzcDsg SW50ZXJuYXRpb25hbCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24gVGVsZWNvbW11bmljYXRpb25z PGJyPg0KICZuYnNwOyBTdGFuZGFyZGl6YXRpb24gU2VjdG9yIChJVFUtVCkgZWZmb3J0IHRvIGlu Y2x1ZGUgYW4gTVBMUyBUcmFuc3BvcnQ8YnI+DQogJm5ic3A7IFByb2ZpbGUgd2l0aGluIHRoZSBJ RVRGIE1QTFMgYW5kIFBXRTMgYXJjaGl0ZWN0dXJlcyB0byBzdXBwb3J0DQp0aGU8YnI+DQogJm5i c3A7IGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzIG9mIGEgcGFja2V0IHRyYW5zcG9y dCBuZXR3b3JrDQphczxicj4NCiAmbmJzcDsgZGVmaW5lZCBieSB0aGUgSVRVLVQuPGJyPg0KPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4N CjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 002F0C76482579EC_=-- From michelg@upperside.fr Thu Apr 26 04:38:17 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2D421F87EA for ; Thu, 26 Apr 2012 04:38:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1tRnC3VH5yj for ; Thu, 26 Apr 2012 04:38:15 -0700 (PDT) Received: from smtp03.msg.oleane.net (smtp03.msg.oleane.net [62.161.4.3]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4221F8592 for ; Thu, 26 Apr 2012 04:38:13 -0700 (PDT) Received: from MichelGosseDel (AClermont-Ferrand-552-1-47-3.w83-113.abo.wanadoo.fr [83.113.150.3]) (authenticated) by smtp03.msg.oleane.net (MSA) with ESMTP id q3QBcAEo007278 for ; Thu, 26 Apr 2012 13:38:10 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: Date: Thu, 26 Apr 2012 13:38:12 +0200 Message-ID: <000001cd23a1$100740b0$3015c210$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD23B1.D3934500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0jlTvHU+bcFCGtQeCrMp2ghwtHZg== Content-Language: fr X-PMX-Spam: Probability=12% X-PFSI-Info: PMX 5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.26.112724 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] MPLS & Ethernet World 2013: Call for proposals X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:38:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CD23B1.D3934500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 15th edition of the MPLS & Ethernet World Congress will take place in Marriott Paris Rive Gauche, from 19 to 22 March, 2013. The call for proposal is online: http://www.uppersideconferences.com/mpls2013/mpls2013cfp.html ------=_NextPart_000_0001_01CD23B1.D3934500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 15th edition of = the MPLS & = Ethernet World Congress will take place in Marriott = Paris Rive Gauche, from 19 to 22 = March, 2013.

 

The call for = proposal is online:

 

http://www.uppersideconferences.com/mpl= s2013/mpls2013cfp.html

 

= ------=_NextPart_000_0001_01CD23B1.D3934500-- From loa@pi.nu Thu Apr 26 06:06:55 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935B121F8773 for ; Thu, 26 Apr 2012 06:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gK2zF0mSg43 for ; Thu, 26 Apr 2012 06:06:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id E1F3821F8770 for ; Thu, 26 Apr 2012 06:06:46 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8FD922A8002; Thu, 26 Apr 2012 15:06:45 +0200 (CEST) Message-ID: <4F994864.50604@pi.nu> Date: Thu, 26 Apr 2012 15:06:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: "mpls@ietf.org" , draft-ietf-mpls-gach-adv@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR's on draft-ietf-mpls-gach-adv and/or draft-ietf-mpls-tp-ethernet-addressing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 13:06:55 -0000 Working Group, The wg chairs prepares two drafts - draft-ietf-mpls-gach-adv; and - draft-ietf-mpls-tp-ethernet-addressing for WG last call. Before the wg last, we would like to check whether there is IPR on the documents that needs to be disclosed. Are you aware of any IPR that applies to the two drafts? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From stbryant@cisco.com Fri Apr 27 06:29:44 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED73621F86A8 for ; Fri, 27 Apr 2012 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqXfsic9DhKe for ; Fri, 27 Apr 2012 06:29:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 10BEE21F86A6 for ; Fri, 27 Apr 2012 06:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=1267; q=dns/txt; s=iport; t=1335533384; x=1336742984; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=M/MfpqtBZALLOLy9mPPJBbBXEEC9VS6ifEWWVY9C2V0=; b=fzhJ4hoTAhxEWtCoEi8xhOuLJE52D7qjHyiFuxKuC7E0+Zw676oQgEAh HE9BCiW/h8MEO8+GiQfgqr5dqeUnuu1KgwZBwRVwC1jCLSR5Ebzy1Pnj+ H0jLkpezz8ohHoToKtiIbAPa1g7Mdkz8P2k1u1N8arFNHmnfLkKysD9ii w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEaemk+Q/khR/2dsb2JhbABEsWqBB4IJAQEBBBIBAiM8BAEQCxgJFg8JAwIBAgFFBg0BBwEBHodrC5xEg0IQnGORQwSVfY5XgQJngmmBWw X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="136431778" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Apr 2012 13:29:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3RDTgdJ027735; Fri, 27 Apr 2012 13:29:42 GMT Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3RDTdkT004065; Fri, 27 Apr 2012 14:29:40 +0100 (BST) Message-ID: <4F9A9F44.7050103@cisco.com> Date: Fri, 27 Apr 2012 14:29:40 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Loa Andersson References: <4F994864.50604@pi.nu> In-Reply-To: <4F994864.50604@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-gach-adv@tools.ietf.org Subject: Re: [mpls] IPR's on draft-ietf-mpls-gach-adv and/or draft-ietf-mpls-tp-ethernet-addressing X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 13:29:45 -0000 I am not personally aware of any undisclosed IPR. Stewart On 26/04/2012 14:06, Loa Andersson wrote: > > Working Group, > > > The wg chairs prepares two drafts > > - draft-ietf-mpls-gach-adv; and > - draft-ietf-mpls-tp-ethernet-addressing > > for WG last call. > > Before the wg last, we would like to check whether > there is IPR on the documents that needs to be disclosed. > > Are you aware of any IPR that applies to the two drafts? > If so, has this IPR been disclosed in compliance with IETF IPR > rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. The documents will not advance to the next stage until a > response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author > or contributor, then please explicitly respond only if you are aware > of any IPR that has not yet been disclosed in conformance with IETF > rules. > > Thanks, Loa > > (as MPLS WG co-chair) -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From xuxiaohu@huawei.com Fri Apr 27 19:55:04 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438BD21F8564 for ; Fri, 27 Apr 2012 19:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiHmH+BXkA2X for ; Fri, 27 Apr 2012 19:55:03 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A5BEB21F8562 for ; Fri, 27 Apr 2012 19:55:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI79465; Fri, 27 Apr 2012 22:55:03 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 19:54:03 -0700 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 27 Apr 2012 19:54:10 -0700 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.252]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Sat, 28 Apr 2012 10:53:22 +0800 From: Xuxiaohu To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-xu-mpls-in-udp-00.txt Thread-Index: AQHNJOUqEV0uAsQuJk6ASHAvdqt8upavh4QA Date: Sat, 28 Apr 2012 02:54:00 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE02F170FE@szxeml525-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "marshall.eubanks@gmail.com" Subject: [mpls] fwd: New Version Notification for draft-xu-mpls-in-udp-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 02:55:04 -0000 SGkgYWxsLA0KDQpFcXVhbCBDb3N0IE11bHRpLVBhdGggKEVDTVApIGFuZCBMaW5rIEFnZ3JlZ2F0 aW9uIEdyb3VwIChMQUcpIGFyZSB3aWRlbHkgdXNlZCBpbiB0aGUgY29yZSBvZiBJUC1lbmFibGVk IFBhY2tldCBTd2l0Y2ggTmV0d29ya3MgKFBTTikgZm9yIGxvYWQtYmFsYW5jaW5nIHB1cnBvc2Vz LiBNb3N0IGNvcmUgcm91dGVycyAoaS5lLiwgUCByb3V0ZXJzKSBpbiB0aGUgSVAtZW5hYmxlZCBQ U04gYXJlIGNhcGFibGUgb2YgbG9hZC1iYWxhbmNpbmcgSVAgdHJhZmZpYyBmbG93cyBhY3Jvc3Mg RUNNUCBwYXRocyBhbmQvb3IgTEFHIGJhc2VkIG9uIHRoZSBoYXNoIG9mIHRoZSBmaXZlLXR1cGxl IG9mICAgVURQL1RDUCBwYWNrZXRzIChpLmUuLCBzb3VyY2UgSVAgYWRkcmVzcywgZGVzdGluYXRp b24gSVAgYWRkcmVzcywgc291cmNlIHBvcnQsIGRlc3RpbmF0aW9uIHBvcnQsIGFuZCBwcm90b2Nv bCkgb3Igc29tZSBmaWVsZHMgaW4gdGhlIElQIGhlYWRlciBvZiBub24tVURQL1RDUCBwYWNrZXRz IChlLmcuLCBzb3VyY2UgSVAgYWRkcmVzcywgZGVzdGluYXRpb24gSVAgYWRkcmVzcykuIA0KDQpI b3dldmVyLCB3aXRoIGV4aXN0aW5nIElQLWJhc2VkIGVuY2Fwc3VsYXRpb24gbWV0aG9kcyBhcyBk ZWZpbmVkIGluIFtSRkM0MDIzXSBzdWNoIGFzIE1QTFMtaW4tSVAgYW5kIE1QTFMtaW4tR1JFLCBk aXN0aW5jdCBjdXN0b21lciB0cmFmZmljIGZsb3dzIG9mIHZhcmlvdXMgTVBMUyBhcHBsaWNhdGlv bnMgKGUuZy4sIE1QTFMtYmFzZWQgTDJWUE4gb3IgTDNWUE4pIGJldHdlZW4gYSBnaXZlbiBQRSBw YWlyIHdvdWxkIGJlIGVuY2Fwc3VsYXRlZCB3aXRoIHRoZSBzYW1lIElQIG9yIEdSRSB0dW5uZWwg aGVhZGVyIHByaW9yIHRvIHRyYXZlcnNpbmcgdGhlIGNvcmUuIFNpbmNlIHRoZSBlbmNhcHN1bGF0 aW5nIHRyYWZmaWMgaXMgbmVpdGhlciBUQ1Agbm9yIFVEUCB0cmFmZmljLCBjb3JlIHJvdXRlcnMg Y291bGQgb25seSBwZXJmb3JtIGhhc2ggY2FsY3VsYXRpb24gb24gdGhlIGZpZWxkcyBpbiB0aGUg SVAgaGVhZGVyIG9mIElQIG9yIEdSRSB0dW5uZWxzLiBBcyBhIHJlc3VsdCwgY29yZSByb3V0ZXJz IGNvdWxkIG5vdCBhY2hpZXZlIGFuIGVmZmVjdGl2ZSBsb2FkLWJhbGFuY2luZyBmb3IgdGhlc2Ug dHJhZmZpYyBmbG93cyBpbiB0aGUgbmV0d29yayBkdWUgdG8gdGhlIGxhY2sgb2YgYWRlcXVhdGUg ZW50cm9weSBpbmZvcm1hdGlvbi4NCg0KVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25lIGFkZGl0 aW9uYWwgSVAtYmFzZWQgZW5jYXBzdWxhdGlvbiB0ZWNobm9sb2d5IGZvciBNUExTIHBhY2tldHMg cmVmZXJyZWQgdG8gYXMgTVBMUy1pbi1VRFAsIHdoaWNoIGlzIGludGVuZGVkIHRvIGZhY2lsaXRh dGUgbG9hZC1iYWxhbmNpbmcgdGhlIHRyYWZmaWMgb2YgdmFyaW91cyBNUExTIGFwcGxpY2F0aW9u cyBzdWNoIGFzIE1QTFMtYmFzZWQgTDJWUE4gYW5kIEwzVlBOIGluIHRoZSBjb3JlIG9mIElQLWVu YWJsZWQgUFNOLg0KDQpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkJlc3QgcmVnYXJkcywN ClhpYW9odQ0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHm l7bpl7Q6IDIwMTLlubQ05pyIMjjml6UgMTA6MTgNCuaUtuS7tuS6ujogWHV4aWFvaHUNCuaKhOmA gTogTHVjeSB5b25nOyBtYXJzaGFsbC5ldWJhbmtzQGdtYWlsLmNvbQ0K5Li76aKYOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1LW1wbHMtaW4tdWRwLTAwLnR4dA0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteHUtbXBscy1pbi11ZHAtMDAudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYg cmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC14dS1tcGxzLWluLXVkcA0KUmV2aXNpb246 CSAwMA0KVGl0bGU6CQkgRW5jYXBzdWxhdGluZyBNUExTIGluIFVEUA0KQ3JlYXRpb24gZGF0ZToJ IDIwMTItMDQtMjgNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBh Z2VzOiA3DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgb25lIGFkZGl0 aW9uYWwgSVAtYmFzZWQgZW5jYXBzdWxhdGlvbg0KICAgdGVjaG5vbG9neSBmb3IgTVBMUyBwYWNr ZXRzIHJlZmVycmVkIHRvIGFzIE1QTFMtaW4tVURQLCB3aGljaCBpcw0KICAgaW50ZW5kZWQgdG8g ZmFjaWxpdGF0ZSBsb2FkLWJhbGFuY2luZyB0aGUgdHJhZmZpYyBvZiB2YXJpb3VzIE1QTFMNCiAg IGFwcGxpY2F0aW9ucyBzdWNoIGFzIE1QTFMtYmFzZWQgTDJWUE4gYW5kIEwzVlBOIGluIHRoZSBj b3JlIG9mIElQLQ0KICAgZW5hYmxlZCBwYWNrZXQgc3dpdGNoIG5ldHdvcmtzLg0KDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From lizho.jin@gmail.com Sat Apr 28 09:33:20 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E9121F85E7 for ; Sat, 28 Apr 2012 09:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.094 X-Spam-Level: X-Spam-Status: No, score=-3.094 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BJrEr9TlbzN for ; Sat, 28 Apr 2012 09:33:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C737B21F85D0 for ; Sat, 28 Apr 2012 09:33:19 -0700 (PDT) Received: by iazz13 with SMTP id z13so2892319iaz.31 for ; Sat, 28 Apr 2012 09:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=BxD3lxRMN22sdLRR7LQuN6AUmDm/7v7Y3ZdmHlHJqO4=; b=bHciXXZluiBQIwNgS+dUjBorxoennm6wYCcfFGllpDLjnU1aFyv/B7LrSuBzQI9X9u W+G7ZFrKG/zdl5WNVVhtNJLgQNiaRC5yqvCTw9jEwSpk74t9LLA0EraHzaRQiaFoNZk0 gZrFRMPS2gHLd7lMM0SfmOmom+gAtkJ4r0lIiTI95+lMhrOvY3vzrYu+0BZfyns7XKek gmMDUKMlEoqw06X6AvZl9prQ9RMZ1gvKfLuWJ+InK5+Basjd/Kms6cvkBxF6b/bRwKUa qxlDul5aYozMs1DTovekIiDd2rck9nhhD9fb4jbuyIVqFwSUSgogiT5TfuWBcW38OfxB 7Zeg== MIME-Version: 1.0 Received: by 10.50.51.197 with SMTP id m5mr6239468igo.38.1335630799320; Sat, 28 Apr 2012 09:33:19 -0700 (PDT) Received: by 10.50.8.100 with HTTP; Sat, 28 Apr 2012 09:33:19 -0700 (PDT) Date: Sun, 29 Apr 2012 00:33:19 +0800 Message-ID: From: Lizhong Jin To: "emily.chenying@huawei.com" Content-Type: multipart/alternative; boundary=14dae934039f58356b04bebfc725 Cc: "mpls@ietf.org" , ice@cisco.com Subject: Re: [mpls] Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 16:33:20 -0000 --14dae934039f58356b04bebfc725 Content-Type: text/plain; charset=ISO-8859-1 Hi Emily, The most concern from me is, since you need to upgrade the non-mLDP node to support the feature in the draft (tunnel through feature), why not upgrade the node to support mLDP directly? What's more, since as you said below, the heavy duty node needs to upgrade with mLDP. How do you know it is a heavy duty node or not? The receiving nodes would change as the time goes. Maybe it is reasonable to consider every node to be potential heavy node, and upgrade every node with mLDP. I doubt if there would be requirement that part of nodes require to upgrade with mLDP, and part of nodes require to upgrade with the feature in the draft? Regards Lizhong Send from my iPad > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 2 Apr 2012 20:43:58 +0000 > From: "Chenying (Emily)" > To: IJsbrand Wijnands > Cc: "mpls@ietf.org" > Subject: Re: [mpls] Scalability with regards to > draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > Message-ID: > < A7F1D242004AC44F834A01185F9389421CD2758E@szxeml537-mbx.china.huawei.com> > > Content-Type: text/plain; charset="us-ascii" > > Dear Ice, > > Thanks for your comments. IMO, the mldp-via-p2p-tunnel and mldp-node-protection mechanisms are under different situations. The following is my 2 cents, please see whether this make sense to you. Thanks. > > The scalability issue would exist only when N node has a large number of downstream routers. In mLDP deployment scenario, if users want to upgrade the network into a mLDP capable one, such 'heavy-duty' N node should be the first priority for upgrade, because it really need packet duplication functionality. Once the N node is upgraded, then t-ldp is not needed, and there is no scalability issue at all. But in mldp-node-protection scenario, such 'heavy-duty' N node should be the first priority for node protection, because it is really important for the multicast tree. Then the t-ldp sessions are always needed, and the scalability issue will always exist. This is why I think the mldp-via-p2p-tunnel and mldp-node-protection mechanisms are under different situations. > > > Best regards, > Emily Chen > > -----Original Message----- > From: IJsbrand Wijnands [mailto:ice@cisco.com] > Sent: Monday, April 02, 2012 12:34 AM > To: Chenying (Emily); Quintin zhao > Cc: mpls@ietf.org > Subject: Scalability with regards to draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00 > > Dear Emily & Quintin, > > The solution in this draft requires a mLDP router upstream of the non-mLDP router to do the packet forwarding and replication. The receiver interest is signaled to the upstream router via tLDP sessions. The upstream router will end up with the number of tLDP session to all the of the receivers downstream of the non-mLDP router, and will have to replicate the multicast packets over P2P LSPs to them.je > > This has exactly the same tLDP scale considerations as discussed in the context of draft-wijnands-mpls-mldp-node-protection-00, yet for mLDP node protection it seems to be a concern for you? > > Thx, > > Ice. > > BTW, we already have had a fair bit of discussion on the list Oct 2011 regarding the other concerns for this draft. > > > ------------------------------ --14dae934039f58356b04bebfc725 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Emily,
The most concern from me is, since you need to upgrade the non= -mLDP node to support the feature in the draft (tunnel through feature), wh= y not upgrade the node to support mLDP directly?
What's more, since = as you said below, the heavy duty node needs to upgrade with mLDP. How do y= ou know it is a heavy duty node or not? The receiving nodes would change as= the time goes. Maybe it is reasonable to consider every node to be potenti= al heavy node, and upgrade every node with mLDP. I doubt if there would be = requirement that part of nodes require to upgrade with mLDP, and part of no= des require to upgrade with the feature in the draft?

Regards
Lizhong

Send from my iPad

> ---------------= -------------------------------------------------------
>
> Mes= sage: 1
> Date: Mon, 2 Apr 2012 20:43:58 +0000
> From: "Ch= enying (Emily)" <emily= .chenying@huawei.com>
> To: IJsbrand Wijnands <ice@cisco.c= om>
> Cc: "mpls@ietf.org= " <mpls@ietf.org>
&g= t; Subject: Re: [mpls] Scalability with regards to
> =A0 =A0 =A0 =A0draft-chen-mpls-mldp-deployment-via-p2p-tunnels-00
&= gt; Message-ID:
> =A0 =A0 =A0 =A0<A7F1D242004AC44F= 834A01185F9389421CD2758E@szxeml537-mbx.china.huawei.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
&g= t;
> Dear Ice,
>
> Thanks for your comments. IMO, the mld= p-via-p2p-tunnel and mldp-node-protection mechanisms are under different si= tuations. The following is my 2 cents, please see whether this make sense t= o you. Thanks.
>
> The scalability issue would exist only when N node has a large= number of downstream routers. In mLDP deployment scenario, if users want t= o upgrade the network into a mLDP capable one, such 'heavy-duty' N = node should be the first priority for upgrade, because it really need packe= t duplication functionality. Once the N node is upgraded, then t-ldp is not= needed, and there is no scalability issue at all. But in mldp-node-protect= ion scenario, such 'heavy-duty' N node should be the first priority= for node protection, because it is really important for the multicast tree= . Then the t-ldp sessions are always needed, and the scalability issue will= always exist. This is why I think the mldp-via-p2p-tunnel and mldp-node-pr= otection mechanisms are under different situations.
>
>
> Best regards,
> Emily Chen
>
> -----= Original Message-----
> From: IJsbrand Wijnands [mailto:ice@cisco.com]
> Sent: Monday, April 02, 2012= 12:34 AM
> To: Chenying (Emily); Quintin zhao
> Cc: mpls@ietf.org
> Subject: Scalability with regards to dr= aft-chen-mpls-mldp-deployment-via-p2p-tunnels-00
>
> Dear Emily= & Quintin,
>
> The solution in this draft requires a mLDP router upstream of = the non-mLDP router to do the packet forwarding and replication. The receiv= er interest is signaled to the upstream router via tLDP sessions. The upstr= eam router will end up with the number of tLDP session to all the of the re= ceivers downstream of the non-mLDP router, and will have to replicate the m= ulticast packets over P2P LSPs to them.je >
> This has exactly the same tLDP scale considerations as discuss= ed in the context of draft-wijnands-mpls-mldp-node-protection-00, yet for m= LDP node protection it seems to be a concern for you?
>
> Thx,<= br> >
> Ice.
>
> BTW, we already have had a fair bit of di= scussion on the list Oct 2011 regarding the other concerns for this draft.<= br>>
>
> ------------------------------
--14dae934039f58356b04bebfc725-- From internet-drafts@ietf.org Sun Apr 29 08:07:37 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 533F021F854E; Sun, 29 Apr 2012 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4gdwHvhDYGC; Sun, 29 Apr 2012 08:07:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769ED21F852D; Sun, 29 Apr 2012 08:07:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120429150736.22426.29005.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 08:07:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ring-protection-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 15:07:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF. Title : Applicability of MPLS-TP Linear Protection for Ring Topo= logies Author(s) : Yaacov Weingarten Stewart Bryant Nurit Sprecher Danielle Ceccarelli Diego Caviglia Francesco Fondelli Marco Corsi Bo Wu Xuehui Dai Filename : draft-ietf-mpls-tp-ring-protection-02.txt Pages : 28 Date : 2012-04-29 This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ From wyaacov@gmail.com Sun Apr 29 08:13:54 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84221F852E for ; Sun, 29 Apr 2012 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XxZWNO+BfGk for ; Sun, 29 Apr 2012 08:13:53 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id ECA3921F84F1 for ; Sun, 29 Apr 2012 08:13:52 -0700 (PDT) Received: by qabj40 with SMTP id j40so1117961qab.15 for ; Sun, 29 Apr 2012 08:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oBWLvtkUWwoasPAuX0uIExoSa/qgTJLUPbRCb6v4+Dg=; b=ef/hLhV7HwTyfomdpeIuxjO/OCRSVM6sGVKn+CT0yCSz17fjYLq7j8aNDOMOfjOaHh usDKuxujgqheEEIai8P3BXtMWBoFk4tV5rR+iOEIxawTm7U4p+OHiO/+PlCKPjTtqBUk MJB8GVHCwLksNlNbBXRc2RnEHuynAs4WICYCHcXTepwrylHIdXIJAXy3T9Ln8K1ncumh oOhX7IfGVMZER7XIuPODg838bF4soNZrAzpiQW33gx17m0Sb3LjeljnXj5P13709XlEC bamKrEGlviSi0+xw6m9/cUZZnZHjbDMaHmWQx5/MGuMnYsxvfVESRi8g5V1tT2gwKYuV DPcw== MIME-Version: 1.0 Received: by 10.224.108.131 with SMTP id f3mr9256473qap.60.1335712432296; Sun, 29 Apr 2012 08:13:52 -0700 (PDT) Received: by 10.229.230.133 with HTTP; Sun, 29 Apr 2012 08:13:52 -0700 (PDT) In-Reply-To: <20120429150736.22426.29005.idtracker@ietfa.amsl.com> References: <20120429150736.22426.29005.idtracker@ietfa.amsl.com> Date: Sun, 29 Apr 2012 18:13:52 +0300 Message-ID: From: Yaacov Weingarten To: mpls@ietf.org Content-Type: multipart/alternative; boundary=20cf3074d56e0c93eb04bed2c915 Subject: Re: [mpls] I-D Action: draft-ietf-mpls-tp-ring-protection-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 15:13:54 -0000 --20cf3074d56e0c93eb04bed2c915 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have just submitted an updated version of the ring-protection applicability draft. The main section that was updated was section 3.2.4 addressing some offline comments received by the authors raising concerns regarding the proposed combination of link and node based wrapping protection. We welcome any additional comments regarding this draft. Best regards, yaacov weingarten On Sun, Apr 29, 2012 at 6:07 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Multiprotocol Label Switching > Working Group of the IETF. > > Title : Applicability of MPLS-TP Linear Protection for > Ring Topologies > Author(s) : Yaacov Weingarten > Stewart Bryant > Nurit Sprecher > Danielle Ceccarelli > Diego Caviglia > Francesco Fondelli > Marco Corsi > Bo Wu > Xuehui Dai > Filename : draft-ietf-mpls-tp-ring-protection-02.txt > Pages : 28 > Date : 2012-04-29 > > This document presents an applicability statement to address the > requirements for protection of ring topologies for Multi-Protocol > Label Switching Transport Profile (MPLS-TP) Label Switched Paths > (LSP) on multiple layers. The MPLS-TP Requirements document > specifies specific criteria for justification of dedicated protection > mechanism for particular topologies, including optimizing the number > of OAM entities needed, minimizing the number of labels for > protection paths, minimizing the number of recovery elements in the > network, and minimizing the number of control and management > transactions necessary. The document proposes a methodology for ring > protection based on existing MPLS-TP survivability mechanisms, > specifically those defined in MPLS-TP Linear Protection, without the > need for specification of new constructs or protocols. > > This document is a product of a joint Internet Engineering Task Force > (IETF) / International Telecommunications Union Telecommunications > Standardization Sector (ITU-T) effort to include an MPLS Transport > Profile within the IETF MPLS and PWE3 architectures to support the > capabilities and functionalities of a packet transport network as > defined by the ITU-T. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf3074d56e0c93eb04bed2c915 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We have just submitted an updated v= ersion of the ring-protection applicability draft.

The main section that was updated was section 3.2.4 addressing some offlin= e comments received by the authors raising concerns regarding the=A0propose= d=A0combination of link and node based wrapping protection.

We welcome any additional comments regarding this draft= .

Best regards,
yaacov weingarten
<= div>

On Sun, Apr 29, 2012 at 6:07 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working= Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Applicability of MPLS-TP Linear= Protection for Ring Topologies
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Yaacov Weingarten
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stewart Bryant
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Nurit Sprecher
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Danielle Ceccarelli
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Diego Caviglia
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Francesco Fondelli
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Marco Corsi
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Bo Wu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Xuehui Dai
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mpls-tp-ring-protectio= n-02.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-29

=A0 This document presents an applicability statement to address the
=A0 requirements for protection of ring topologies for Multi-Protocol
=A0 Label Switching Transport Profile (MPLS-TP) Label Switched Paths
=A0 (LSP) on multiple layers. =A0The MPLS-TP Requirements document
=A0 specifies specific criteria for justification of dedicated protection<= br> =A0 mechanism for particular topologies, including optimizing the number =A0 of OAM entities needed, minimizing the number of labels for
=A0 protection paths, minimizing the number of recovery elements in the =A0 network, and minimizing the number of control and management
=A0 transactions necessary. =A0The document proposes a methodology for rin= g
=A0 protection based on existing MPLS-TP survivability mechanisms,
=A0 specifically those defined in MPLS-TP Linear Protection, without the =A0 need for specification of new constructs or protocols.

=A0 This document is a product of a joint Internet Engineering Task Force<= br> =A0 (IETF) / International Telecommunications Union Telecommunications
=A0 Standardization Sector (ITU-T) effort to include an MPLS Transport
=A0 Profile within the IETF MPLS and PWE3 architectures to support the
=A0 capabilities and functionalities of a packet transport network as
=A0 defined by the ITU-T.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= ietf-mpls-tp-ring-protection-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ie= tf-mpls-tp-ring-protection-02.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp= -ring-protection/

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf3074d56e0c93eb04bed2c915-- From adrian@olddog.co.uk Mon Apr 30 05:50:00 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF3E21F861D for ; Mon, 30 Apr 2012 05:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTaZmw4PzW4s for ; Mon, 30 Apr 2012 05:49:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8026621F8617 for ; Mon, 30 Apr 2012 05:49:55 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3UCnrEj017639; Mon, 30 Apr 2012 13:49:53 +0100 Received: from 950129200 (customer57388.107.wv.cust.t-mobile.co.uk [178.107.224.43] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q3UCni63017519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Apr 2012 13:49:46 +0100 From: "Adrian Farrel" To: Date: Mon, 30 Apr 2012 13:49:42 +0100 Message-ID: <074201cd26cf$b9992680$2ccb7380$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0mz4hBtCcv693CRmyJMqbRVddUsA== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ldp-gtsm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 12:50:00 -0000 Hello authors of draft-ietf-mpls-ldp-gtsm, I have conducted my usual AD review of your draft in response to the publication request from the WG. This, of itself, is not reason to induce panic :-) My review has yielded a number of questions and nits. All of the points are open for discussion and I am not mandating changes. But I think that there are enough issues here to warrant a new revision. I have put the document into "revised I-D" state and look forward to a new version or a lively email debate. Thanks, Adrian --- I am confused by whether you propose GTSM to be enabled by default. Section 1 says... GTSM specifies that it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol Section 1.2 says... GTSM and will require (statically or dynamically) disabling GTSM. See Section 3. Section 3 says... The reason GTSM is enabled for Basic Discovery by default Indeed, 5082 says... 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis. In fact, I don't think GTSM is enabled by default in your document. I think what you have is that the desire to use GTSM (i.e., the negotiation to use it) is enabled by default in implementations of your spec. But this is subtly different from what the text says. --- Can you tidy the English in Section 1. Suggested... OLD GTSM specifies that it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol; this document specifies having a built-in dynamic GTSM capability negotiation for LDP to suggest the use of GTSM, provided GTSM is not enabled unless both peers can detect each others' support for GTSM procedures and agree on its usage as described in this document. NEW GTSM specifies that it should not be enabled by default; this facilitates backward-compatibility with the unmodified protocol. This document specifies a dynamic negotiation for the an LDP peer to suggest the use of GTSM. GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM and agree to use it. END Note the change s/SHOULD NOT/should not/. This text in Section 1 is not defining any protocol behavior and comes before the citation of RFC 2119. It doesn't need to use upper case. --- You need to do some work to expand acronyms on first use if they are not listed with an asterisk at: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I found: LSR --- Is it time to define an IANA registry for the common Hello parameters bit fields? Had one existed, you would not have needed to update 5036. If you create one now, future bit users will not have to update your RFC. --- Section 2.1 The G flag is meaingful only if T and R flags are set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. This is clear for the T flag: the use of GTSM is not supported for targeted (extended) Hellos. Why is this the case for the R flag? The use of the R flag is making a request, not demanding use. It might be the normal case that you would not set the R flag unless you were more than one hop away, but it does not follow that this is the case, does it? As indicated in RFC 5036, a Hello receiver that does not support targeted Hellos ignores the request (i.e., the R flag). That would clear it to support the G flag. --- Section 2.1 Any LSR not supporting GTSM for LDP, as defined in this document, would continue to ignore the G flag, independent of T and R flags' value, as per Section 3.5.2 of [RFC5036]. I think you need to cover two cases. As it happens the behavior you are asking for is the same, but I think you need to call out the two cases separately: 1. An LSR that does not recognise the G flag. 2. An LSR that does recognise the G flag but does not support GTSM (either through implementation or configuration). --- Section 2.2 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello messages to link-level multicast address (224.0.0.2 or "all routers"). Such messages are never forwarded beyond one hop and assumed to have their IP TTL or Hop Count = 1. This assumption is, I think, new in your document. I can't find anything about this in 5036 (although I may have missed it). I suspect you need to change this from an assumption to a RECOMMENDation --- Section 2.2 An LSR that is capable of applying GTSM procedures to the subsequent TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello message [RFC5036]. "capable" is such an interesting word :-) And the text here is interesting. Does this cut into the discussion of defaults above? What you are saying is that a device that has been coded to support GTSM has to negotiate its use regardless of operator preferences. Why? How would the following look? Unless configured otherwise, an LSR that supports GTSM sets the G flag (for GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello message [RFC5036]. --- Section 2.2 An LSR, upon receiving an LDP Link Hello message, would recognize the presence of G flag (in Common Hello Parameter TLV) only if it supports GTSM for LDP, as specified in this document. This is not true :-( You are updating 5036 so all new implementations will recognise the G flag whether or not they support GTSM. --- Section 2.2 If an LSR recognizes the presence of G flag with the value =1 in the received LDP Link Hello message, then it MUST enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message, as specified in Section 2.3 of this document. Again, this does not offer the operator any control or choice in the matter. Why is the use of GTSM not configurable? --- Section 2.2 If an LSR that has sent the LDP Link Hello with G flag = 1, then the LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP Transport Connection(s) with that neighbor (e.g., LSR2). Please see Section 2.3 for more details about the TCP transport connection specifics. Why is this MUST? What if the peer has responded with G=0 indicating it doesn't support (or want to use) GTSM? Surely, in that case, the local LSR can set any TTL. BTW Why is this paragraph in Section 2.2? --- I think the mentions of "LSR2" in sections 2.2 and 2.3 are a little unnecessary. --- Are we missing a discussion of what happens if the value of G changes on a subsequent Hello? --- Section 3 Typo s/en the third case/In the third case/ --- Section 5 Suppose I touch the setting of the G flag in transit? That means that LDP Hello security is more important, right? --- Section 5 Shouldn't you make reference to the security section of 5082. In particular, you need to highlight the things GTSM does not protect against. --- I believe your document should give stronger hints than the generic comments in 5082 about what should be done with an LDP message that "fails" a GTSM TTL check. This is appropriate because you are writing a protocol-specific application of GTSM. From jerdenebold@isocore.com Mon Apr 30 17:01:48 2012 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B121F8575 for ; Mon, 30 Apr 2012 17:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvf0hDyrzUHa for ; Mon, 30 Apr 2012 17:01:47 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0E21F860E for ; Mon, 30 Apr 2012 17:01:47 -0700 (PDT) Received: from [65.213.193.93] (port=57125 helo=VinceHP) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.77) (envelope-from ) id 1SP0X8-0004pQ-Up for mpls@ietf.org; Mon, 30 Apr 2012 20:01:35 -0400 From: "Julia Erdenebold" To: References: <80CAFB37-DF32-45AA-9D95-0C74E4BA935F@lucidvision.com> <015701cd2171$926cd740$b74685c0$@isocore.com> In-Reply-To: Date: Mon, 30 Apr 2012 20:01:38 -0400 Message-ID: <00ba01cd272d$948d4430$bda7cc90$@isocore.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01CD270C.0D7BA430" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIBuzB0v8t+/yW0CdN6BmeIR4W1rwK781LNljTAx7CAAANIEA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Subject: [mpls] FW: The MPLS 2012 International Conference Call For Papers X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:01:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BB_01CD270C.0D7BA430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Due to numerous requests, we are extending the deadline for the submission of Call for Presentation abstract to Friday May 11. Please make sure to submit your abstracts to mpls2012-cfp@isocore.com. For further information, please refer to http://www.isocore.com/mpls2012/call_for_papers/cfp.htm. Regards, Julia The MPLS 2012 International Conference, the 15th Annual International Conference on MPLS and Related Technologies, will be held October 28 - 31, 2012, in Washington, DC. The Technical Program Committee is soliciting abstracts summarizing a proposed presentation representing original/unpublished work covering cutting-edge topics. Presentations covering new technologies and operational experience are solicited from network equipment vendors, service/transport providers, government agencies, the research community, and enterprise users. The deadline for submission of presentation proposals is April 30, 2012. If you want further information on MPLS 2012 or want to submit a presentation abstract, please see the following URL: http://www.isocore.com/mpls2012/call_for_papers/cfp.htm Many of these topics have been of interest to members of in the past, and many people active on this list have been presenters at past events. ------=_NextPart_000_00BB_01CD270C.0D7BA430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Due to = numerous requests, we are extending the deadline for the submission of = Call for Presentation abstract to Friday May 11. Please make sure to = submit your abstracts to mpls2012-cfp@isocore.com.

 

For = further information, please refer to http://www.isocore.com/mpls2012/call_for_paper= s/cfp.htm.

 

Regards,

Julia

 

 

The MPLS = 2012 International Conference, the 15th Annual = International

Conference = on MPLS and Related Technologies, will be held October 28 = -

31, 2012, in = Washington, DC. The Technical Program Committee = is

soliciting = abstracts summarizing a proposed presentation = representing

original/unpu= blished work covering cutting-edge = topics.

 

Presentations= covering new technologies and operational experience = are

solicited = from network equipment vendors, service/transport = providers,

government = agencies, the research community, and enterprise = users.

The deadline = for submission of presentation proposals is April 30, = 2012.

If you want = further information on MPLS 2012 or want to submit = a

presentation = abstract, please see the following = URL:

 

 

Many of = these topics have been of interest to members of <this = community>

in the past, = and many people active on this list have = been

presenters = at past events.

------=_NextPart_000_00BB_01CD270C.0D7BA430--