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

From: Xuxiaohu <[email-masked]>
Date: Wed, 3 Aug 2016 08:54:07 +0000

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-over-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 would like to hear more suggestions and comments from MPLS and SPRING WGs on the necessity of RFC3031bis and the best way to standardize the remote label distribution peer mode for MPLS SR. 

Best regards,
Xiaohu

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Wednesday, April 06, 2016 11:37 PM
> To: [email-masked]
> Cc: [email-masked]
> 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-mpls) 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-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: <[email-masked]>
Date: Wed, 3 Aug 2016 10:33:26 +0000

Xiaohu,

> From: spring [mailto:[email-masked]] On Behalf Of Xuxiaohu > Sent: Wednesday, August 03, 2016 10:54 AM
> 
> 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-over-
> 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?
- 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?
- On the specification standpoint, your draft is informational, so is not going to change an existing standard track document.

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.

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.

> 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

> and the best way to standardize the remote label distribution peer mode for MPLS SR.

IMHO this part seems primarily for the SPRING WG.

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.

Regards,
--Bruno

> spring mailing list
> [email-masked]
> 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.

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 4 Aug 2016 03:27:46 +0000

Hi Bruno,

Thanks a lot for your detailed clarification. Please see my response inline.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 03, 2016 6:33 PM
> To: Xuxiaohu
> Cc: [email-masked]; [email-masked]
> Subject: RE: Clarification on the motivation of
> > From: spring [mailto:[email-masked]] On Behalf Of Xuxiaohu >
> > Sent: Wednesday, August 03, 2016 10:54 AM
> >
> > 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-over-
> > 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).
> 
> 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. 

> 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?).

> 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

> > > 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.
> > >
> > > (https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls)
> > > 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:
> > >
> > > 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.
> > >
> > > /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:
> > >
> > > (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
> _____________________________________________________________
> ____________________________________________________________
> 
> 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.

---

From: <[email-masked]>
Date: Thu, 4 Aug 2016 08:18:04 +0000

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.

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.
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

> From: Xuxiaohu [mailto:[email-masked]]
> Sent: Thursday, August 04, 2016 5:28 AM
> To: DECRAENE Bruno IMT/OLN
> Subject: RE: Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05
> 
> Hi Bruno,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> >
> 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?).
> 
> 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
> > >

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 4 Aug 2016 09:32:39 +0000

Hi Bruno,

> Sent: Thursday, August 04, 2016 4:18 PM
> To: Xuxiaohu
> > 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?
> 
> 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. 

> > 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:
> 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
> 
> > > > However, the remote label distribution peer mode for MPLS SR
> > > > (which is used for connecting MPLS SR
> > > > 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
> > > 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).
> > >
> > > 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 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
> > >
> > 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.
> > >
> > > 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
> > > >
> > > > > According to suggestions from SPRING co-chairs, I would clarify
> > > > > the intention of this draft
> > > > > (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:
> > > > >
> > > > > 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
> > > > > /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:
> > > > >
> > > > > -ip-05) describes the remote label distribution peer mode which
> > > > > is useful for incremental deployment purpose.
> > > > >
> > > 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.
> 
>