Hi Bruno, > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Thursday, August 04, 2016 4:18 PM > To: Xuxiaohu > Cc: [email protected]; [email protected] > 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:[email protected]] > > Sent: Thursday, August 04, 2016 5:28 AM > > To: DECRAENE Bruno IMT/OLN > > Cc: [email protected]; [email protected] > > 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: [email protected] [mailto:[email protected]] > > > Sent: Wednesday, August 03, 2016 6:33 PM > > > To: Xuxiaohu > > > Cc: [email protected]; [email protected] > > > Subject: RE: Clarification on the motivation of > > > draft-xu-spring-islands-connection-over-ip-05 > > > > > > Xiaohu, > > > > > > > From: spring [mailto:[email protected]] 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:[email protected]] On Behalf Of Xuxiaohu > > > > > Sent: Wednesday, April 06, 2016 11:37 PM > > > > > To: [email protected] > > > > > Cc: [email protected] > > > > > 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 > > > > > [email protected] > > > > > https://www.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ > > > > spring mailing list > > > > [email protected] > > > > 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. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
