Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

[Xuxiaohu <[e-mail]>]

Hi Bruno,

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