Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
Xuxiaohu <xuxiaohu@huawei.com> Thu, 04 August 2016 09:32 UTC
Return-Path: <xuxiaohu@huawei.com>
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 2939412D882; Thu, 4 Aug 2016 02:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Level:
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBCdmYEZ_uzM; Thu, 4 Aug 2016 02:32:52 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8DF12D883; Thu, 4 Aug 2016 02:32:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COW36235; Thu, 04 Aug 2016 09:32:49 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Aug 2016 10:32:46 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 4 Aug 2016 17:32:40 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>
Thread-Topic: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
Thread-Index: AQHRkBgULgoheUag70W81YSz/dG9VqA3nkqQgAAXzDCAAQtyYIAAaEsQgAAMaMA=
Date: Thu, 04 Aug 2016 09:32:39 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E2DB@NKGEML515-MBX.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D538182@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57DE74@NKGEML515-MBX.china.huawei.com> <19854_1470220407_57A1C877_19854_718_1_53C29892C857584299CBF5D05346208A0F974069@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D57E19C@NKGEML515-MBX.china.huawei.com> <24264_1470298685_57A2FA3D_24264_942_1_53C29892C857584299CBF5D05346208A0F97F3A1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
In-Reply-To: <24264_1470298685_57A2FA3D_24264_942_1_53C29892C857584299CBF5D05346208A0F97F3A1@OPEXCLILM21.corporate.adroot.infra.ftgroup>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57A30BC1.0326, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 43e7d5472f6d6bcf2e537bbc364b06bf
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/x4Bo7Q0q6aMjSs_u3eFTs6HNmv0>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2016 09:32:56 -0000
Hi Bruno, > -----Original Message----- > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > Sent: Thursday, August 04, 2016 4:18 PM > To: Xuxiaohu > Cc: mpls@ietf.org; spring@ietf.org > Subject: RE: Clarification on the motivation of > draft-xu-spring-islands-connection-over-ip-05 > > Xiaohu, > > 1) Trying to summarize your email: > > > It seems no need to modify RFC3031 if the remote label distribution > > peer mode for MPLS- SR could be endorsed by the SPRING WG (or MPLS > WG?). > > On the MPLS side, you don't have an issue with any MPLS document. All you > need is " the remote label distribution peer mode for MPLS-SR". > Is this correct? > > On the SPRING side, what you are asking is "the remote label distribution mode > for MPLS-SR". > Is this correct? > > > 2) On my side, it's still not clear to me what you mean by "the remote label > distribution mode for MPLS-SR" > In particular MPLS-SR is all about stacking labels from remote peers, so it seems > to me that the "remote label distribution mode for MPLS-SR" is there from day > 1. For a given MPLS-SR node, it could act as a remote label distribution peer for any FECs other than itself from day 1. However, what's needed for connecting MPLS-SR nodes over IP is to allow an MPLS-SR node to act as a remote label distribution peer "for itself" when the IGP next-hop from that MPLS-SR node is a non-MPLS-SR node. For instance, when receiving an MPLS packet with its top label indicating a given SR node, if the IGP next-hop towards that SR node is a non-MPLS-SR node, that MPLS packet could be transported over an IP tunnel towards that SR node. > 3) Regarding your specific issue with RFC 3031 > > > when > > an MPLS-SR-enabled router X receives an MPLS packet with the top > > indicating a given node segment Y, if the next-hop router of the best > > path to Y is a non-MPLS router, X couldn't map the packet's top label > > into an Next Hop Label Forwarding Entry (NHLFE) , even though the top > > label itself is a valid incoming label. As a result, X would have to drop that > packet according to RFC3031 (see Section 3.22. Lack of Outgoing Label). > > RFC 3031 says: > " When a labeled packet is traveling along an LSP, it may occasionally > happen that it reaches an LSR at which the ILM does not map the > packet's incoming label into an NHLFE, even though the incoming label > is itself valid." > > https://tools.ietf.org/html/rfc3031#section-3.22 > > In your use case, you would have a NHLFE. It would be the IP tunnel to the > egress (considered as a virtual interface if you want) plus swapping the incoming > label with the label of the egress for this FEC. Your description of such implementation is correct. However, such implementation is not obvious and not standard-compliance and therefore we need a draft to describe it. The reason why SR-LDP implementation needs a draft is applicable to this implementation as well, IMHO. Best regards, Xiaohu > In my understanding, this section describes the forwarding plane behavior when > no NHLFE is present. While what you are talking about is the control plane > behavior to build this NHLFE. So I'm not seeing that RFC 3031 prohibits your use > case. > > Regards, > Bruno > > > -----Original Message----- > > From: Xuxiaohu [mailto:xuxiaohu@huawei.com] > > Sent: Thursday, August 04, 2016 5:28 AM > > To: DECRAENE Bruno IMT/OLN > > Cc: mpls@ietf.org; spring@ietf.org > > Subject: RE: Clarification on the motivation of > > draft-xu-spring-islands-connection-over-ip-05 > > > > Hi Bruno, > > > > Thanks a lot for your detailed clarification. Please see my response inline. > > > > > -----Original Message----- > > > From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com] > > > Sent: Wednesday, August 03, 2016 6:33 PM > > > To: Xuxiaohu > > > Cc: mpls@ietf.org; spring@ietf.org > > > Subject: RE: Clarification on the motivation of > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > Xiaohu, > > > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > > > > Xuxiaohu > > > > > Sent: Wednesday, August 03, 2016 10:54 AM > > > > > > > > Hi MPLS WG and SPRING WG, > > > > > > > > I have been told by many people that connecting MPLS segment > > > > routing > > > > (SR) islands/nodes over IP as described in > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection-ov > > > > er- > > > > ip-05) is very useful for the incremental deployment of MPLS SR. > > > > However, the remote label distribution peer mode for MPLS SR > > > > (which is used for connecting MPLS SR > > > > islands/nodes) conflicts with RFC3031 (see Section 3.22. Lack of > > > > Outgoing Label). I discussed with Bruno (SPRPING WG co-chair) > > > > offline about the next step of this draft at IETF96. he suggested > > > > that it'd better to update RFC3031 so as to take the remote label > > > > distribution peer > > > mode for MPLS SR into account. > > > > > > I think that you are referring to a private conversation that we had > > > during the Bits-N-Bites, Thursday evening. To be clear, on my side, > > > I assumed that this was a private conversation over a few beers. (and thanks > Juniper for the beers). > > > > > > Then, this is not what I said. > > > > > > Coming back to the technical point: > > > First of all, it's not clear to me what, according to you, is > > > missing in the current IETF specifications, to allow for your use case. > > > - On the data plane standpoint, multiple forms of IP tunnels are > > > capable of carrying MPLS packets. Presumably to be able to send MPLS > > > packets between MPLS nodes which are not adjacent but separated by > > > IP routers. Do we agree on this, or is something missing? > > > > This draft doesn't talk about specific IP tunneling technologies for > > carrying MPLS packets which have been specified in other RFCs (e.g., > > RFC4023 and RFC7510). Instead, it talks about the remote label distribution > peer mode for MPLS-SR. > > > > > - On the control plane standpoint, the draft is very light on this, > > > but according to the discussion, both tunnels end-points are MPLS > > > segment routing capable and advertise their labels (index) in the > > > IGP. So we do have the labels of the IP tunnel egress/remote end point. Is > there something missing? > > > > This draft doesn't talk about control plane protocols either. > > Labels/indexes are advertised by using IGP extensions for SR. > > Tunneling capabilities are advertised by using the mechanisms as > > described in > > (https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap) > > and (https://tools.ietf.org/html/draft-xu-isis-encapsulation-cap) > > Instead, it talks about the remote label distribution peer mode for MPLS-SR. > > > > > - On the specification standpoint, your draft is informational, so > > > is not going to change an existing standard track document. > > > > Maybe this draft should be "Standard Track" as the SR-LDP > > interoperation implementation draft > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop) > since both of them are internal implementation related. > > > > > So it looks like to me that you could locally do what you want, e.g. > > > assume that the IP tunnel is a virtual MPLS link/shortcut to the > > > egress (even though not advertised in the IGP), and send the MPLS SR packet > over that tunnel. > > > > That's the remote label distribution mode for MPLS-SR which is not > > obvious as T-LDP or L- BGP. BTW, it seems not obvious like the SR-LDP > > interoperation implementation (Note that we have ever done LDP-LBGP > > interoperation implementation(not LBGP over LDP) many years before)). > > Since we have a draft to describe SR-LDP interoperation > > implementation, we should have a draft to describe the remote label > > distribution mode for MPLS-SR as well, since they are alternatives for > incremental deployment of MPLS-SR: one is more suitable for greenfield case > while the other is more suitable for brownfield case. > > > > > Then you replied that, even if it's a local behavior, a MPLS RFC prohibited > this. > > > Then I replied that this looks like a work for the MPLS WG. e.g. if > > > a MPLS RFC prohibits this behavior, you need to discuss this in the > > > MPLS WG, and if needed, have this MPLS RFC updated. > > > > Provided the remote label distraction peer mode for MPLS-SR was not > > standardized, when an MPLS-SR-enabled router X receives an MPLS packet > > with the top indicating a given node segment Y, if the next-hop router > > of the best path to Y is a non-MPLS router, X couldn't map the > > packet's top label into an Next Hop Label Forwarding Entry (NHLFE) , > > even though the top label itself is a valid incoming label. As a > > result, X would have to drop that packet according to RFC3031 (see > > Section 3.22. Lack of Outgoing Label). In contrast, assume the remote > > label distribution peer mode for MPLS-SR is standardized, that packet > > could be transported over an IP tunnel towards Y instead of being dropped. > Now this special implementation becomes standard-compliance, rather than > proprietary. IMHO, this situation is almost the same as the SR-LDP > interoperation implementation. > > > > > > > > > I would like to hear more suggestions and comments from MPLS and > > > > SPRING WGs on the necessity of RFC3031bis > > > > > > IMHO this part seems primarily for the MPLS WG > > > > It seems no need to modify RFC3031 if the remote label distribution > > peer mode for MPLS- SR could be endorsed by the SPRING WG (or MPLS > WG?). > > > > > > and the best way to standardize the remote label distribution peer > > > > mode for > > > MPLS SR. > > > > > > IMHO this part seems primarily for the SPRING WG. > > > > Agree. Any comments and suggestions on the remote label distribution > > peer mode for MPLS-SR are welcome. > > > > > MPLS SR uses routing protocols to advertise labels, more > > > specifically link state IGP (OSPF, IS-IS) or BGP. Can you elaborate > > > on what is missing? Again, the draft is light on this (to say the > > > least). According to our discussion, nodes share the same IGP, hence > > > they should already have the labels. In all cases, your half-page draft is not > proposing something new on the label distribution standpoint. > > > > It's no problem to make this draft more detailed as long as the WG > > believes this work (i.e., standardize the remote label distribution peer mode > for MPLS-SR) is worthwhile to do. > > > > Best regards, > > Xiaohu > > > > > Regards, > > > --Bruno > > > > > > > > > > > Best regards, > > > > Xiaohu > > > > > > > > > -----Original Message----- > > > > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Xuxiaohu > > > > > Sent: Wednesday, April 06, 2016 11:37 PM > > > > > To: spring@ietf.org > > > > > Cc: mpls@ietf.org > > > > > Subject: [mpls] Clarification on the motivation of > > > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > > > > > Hi all, > > > > > > > > > > According to suggestions from SPRING co-chairs, I would clarify > > > > > the intention of this draft > > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection- > > > > > over > > > > > -ip-05) as follows. > > > > > > > > > > If I understood the current MPLS-SR specification > > > > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-m > > > > > pls) correctly, the IGP next-hop for a given /32 or /128 prefix > > > > > FEC (i.e., node segment prefix) is taken as the next-hop of the > > > > > received MPLS packet belonging to that FEC. When the IGP > > > > > next-hop for that FEC is a non-MPLS node, the outgoing label for > > > > > that FEC is lacked. > > > > > As a result, the received MPLS packet belonging to that FEC > > > > > would be dropped BY DEFAULT according to the following > > > > > specification as quoted from > > > > > RFC3031: > > > > > > > > > > "3.22. Lack of Outgoing Label > > > > > When a labeled packet is traveling along an LSP, it may occasionally > > > > > happen that it reaches an LSR at which the ILM does not map the > > > > > packet's incoming label into an NHLFE, even though the incoming > label > > > > > is itself valid. This can happen due to transient conditions, or due > > > > > to an error at the LSR which should be the packet's next hop. > > > > > It is tempting in such cases to strip off the label stack and attempt > > > > > to forward the packet further via conventional forwarding, based on > > > > > its network layer header. However, in general this is not a safe > > > > > procedure: > > > > > - If the packet has been following an explicitly routed LSP, this > > > > > could result in a loop. > > > > > - The packet's network header may not contain enough > > > information > > > > > to enable this particular LSR to forward it correctly. > > > > > Unless it can be determined (through some means outside the scope > of > > > > > this document) that neither of these situations obtains, the only > > > > > safe procedure is to discard the packet." > > > > > > > > > > In the T-LDP or L-BGP case, the next-hop for the MPLS packet > > > > > belong to a given prefix FEC is not the IGP next-hop of that FEC anymore. > > > > > For instance, in the T-LDP case, the next-hop is the T-LDP peer, > > > > > and in the L-BGP case, the next-hop is the L-BGP peer. As a > > > > > result, if T-LDP peers or L-BGP peers are not directly connected > > > > > and are separated by an IP network, the LSP signaled by T-LDP or > > > > > L-BGP could be > > > transported over that IP network. > > > > > > > > > > The situation in MPLS-SR is a little bit complex since the > > > > > outgoing label for a given > > > > > /32 or /128 prefix FEC could be learnt either from the IGP > > > > > next-hop of that FEC or the originator of that FEC due to the > > > > > IGP flooding property. In the former case, the IGP next-hop for > > > > > a given FEC is taken as the next-hop of the received MPLS packet > > > > > belonging to that FEC; in the latter case, the originator of > > > > > that FEC is taken as the next-hop of the MPLS packet belonging > > > > > to that FEC. The former case is straightforward to understand > > > > > and has been described in the current MPLS-SR draft. the latter > > > > > case is a bit hard to understand and has not been described in > > > > > the current MPLS-SR drafts. In fact, the latter > > > case belongs to the "remote label distribution peer" case as defined > > > in RFC3031, see below: > > > > > > > > > > "When two LSRs are IGP neighbors, we will refer to them as "local > > > > > label distribution peers". When two LSRs may be label > distribution > > > > > peers, but are not IGP neighbors, we will refer to them as > "remote > > > > > label distribution peers." > > > > > > > > > > In a word, this draft > > > > > (https://tools.ietf.org/html/draft-xu-spring-islands-connection- > > > > > over > > > > > -ip-05) describes the remote label distribution peer mode which > > > > > is useful for incremental deployment purpose. > > > > > > > > > > I would like to hear from SPRING and MPLS WGs whether the remote > > > > > label distribution peer mode is valid for MPLS-SR and whether we > > > > > need a draft to describe the remote label distribution peer mode > > > > > for > > > MPLS-SR. > > > > > > > > > > Best regards, > > > > > Xiaohu > > > > > _______________________________________________ > > > > > mpls mailing list > > > > > mpls@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > _____________________________________________________________ > > > > ____________________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations > > > confidentielles ou privilegiees et ne doivent donc pas etre > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > > ce message par erreur, veuillez le signaler a l'expediteur et le > > > detruire ainsi que les pieces jointes. Les messages electroniques > > > etant susceptibles d'alteration, Orange decline toute responsabilite si ce > message a ete altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or > > > privileged information that may be protected by law; they should not > > > be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender > > > and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that > > > have been modified, changed or falsified. > > > Thank you. > > > _____________________________________________________________ > ____________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, Orange decline toute responsabilite > si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, used > or copied without authorisation. > If you have received this email in error, please notify the sender and delete this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you.
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… bruno.decraene
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… bruno.decraene
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- [mpls] Clarification on the motivation of draft-x… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… Eric C Rosen
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… Uma Chunduri
- Re: [mpls] Clarification on the motivation of dra… Eric C Rosen
- Re: [mpls] Clarification on the motivation of dra… Eric C Rosen
- Re: [mpls] Clarification on the motivation of dra… Uma Chunduri
- Re: [mpls] Clarification on the motivation of dra… Uma Chunduri
- Re: [mpls] Clarification on the motivation of dra… Carlos Pignataro (cpignata)
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu
- Re: [mpls] Clarification on the motivation of dra… Xuxiaohu