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

From: Xuxiaohu <[email-masked]>
Date: Wed, 6 Apr 2016 15:37:21 +0000

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

---

From: Eric C Rosen <[email-masked]>
Date: Wed, 6 Apr 2016 16:48:24 -0400

On 4/6/2016 11:37 AM, Xuxiaohu wrote:
> 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 latter case belongs to the "remote label distribution peer" case as defined in RFC3031

I don't believe this is correct.  In SR, the fact that label L was 
advertised by node N does not imply that a packet with L at the top of 
the stack needs to be tunneled to N.  In the typical case, the packet 
would just follow the IGP best path, and all the intermediate nodes 
would be expected to recognize the label at the top of the stack.  If 
the intermediate nodes are expected to recognize the label,  this is not 
the "remote label distribution peer case".

You seem to be positing a case where two nodes are in the same IGP 
domain, and same SPRING domain, but there is no LSP that can be used to 
transport packets from one to the other.   It would be somewhat unusual 
to have an IGP domain in which some nodes support MPLS and some don't.  
In BIER, we do accommodate this sort of situation, where some of the 
nodes in the BIER domain do not support BIER.  But I don't know whether 
that sort of scenario needs to be supported for MPLS-SR.  Do you have a 
particular use case in mind?

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 6 Apr 2016 23:56:55 +0000

Hi Eric,

Thanks a lot for your comments. Your observation is correct that I'm  positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to
transport packets from one to the other.

One particular use case in mind is the MPLS-SR based service function chaining where the service function path is represented by a stack of labels (see https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring). In other words, the SFC encapsulation header is realized in the form of an MPLS label stack. One of the major requirement for the SFC encapsulation header is transport-independancy. That means the SFC encapsulation header in the form of an MPLS label stack should be able to be transported over IP networks. To meet the above requirement, one MPLS-SR node (e.g., service classifier or SFF) should be able to forward a received MPLS packet to another MPLS-SR node (e.g., SFF) which is indicated by the top label of the received packet via an IP-based tunnel, when the IGP next-hop towards the latter MPLS-SR node is a non-MPLS node.

Best regards,
Xiaohu

________________________________________
发件人: Eric C Rosen [[email-masked]]
发送时间: 2016年4月7日 4:48
收件人: Xuxiaohu; [email-masked]
抄送: [email-masked]
主题: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 7 Apr 2016 22:39:41 +0000

Hi Eric,

[Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label of L is desired to forward that MPLS packet towards node N via an IP-based tunnel. In this case, the node N is the remote peer for that FEC.

Best regards,
Xiaohu

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 8 Apr 2016 01:28:00 +0000

> It would be somewhat unusual

May be true with non-SR and traditional  MPLS. 
But with SR I am working with one customer where MPLS (as SR data plane) is brought into their pure IGP-IP domain.
With static PW labels (inner label)  currently pure soft GRE encap is being used (for transport)  but SR is being planned from EPG to cell site routers eventually. 
Planning slow upgrade for some of the MBH nodes with SR-MPLS data plane.  In this case its quite possible to use (in future) non-shortest path SR label stack.
Thx!
--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, April 07, 2016 3:40 PM
To: Eric C Rosen; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

Hi Eric,

On 4/6/2016 11:37 AM, Xuxiaohu wrote:
> 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 latter case belongs to the "remote label distribution peer" case 
> as defined in RFC3031

I don't believe this is correct.  In SR, the fact that label L was advertised by node N does not imply that a packet with L at the top of the stack needs to be tunneled to N.  In the typical case, the packet

Best regards,
Xiaohu

would just follow the IGP best path, and all the intermediate nodes would be expected to recognize the label at the top of the stack.  If the intermediate nodes are expected to recognize the label,  this is not the "remote label distribution peer case".

You seem to be positing a case where two nodes are in the same IGP domain, and same SPRING domain, but there is no LSP that can be used to
transport packets from one to the other.   It would be somewhat unusual
to have an IGP domain in which some nodes support MPLS and some don't.
In BIER, we do accommodate this sort of situation, where some of the nodes in the BIER domain do not support BIER.  But I don't know whether that sort of scenario needs to be supported for MPLS-SR.  Do you have a particular use case in mind?
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 11 Apr 2016 14:50:44 -0400

> [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label…

Yes, in this case, the tunnel's receive endpoint can be regarded as a 
remote label distribution peer of the tunnel's  transmit endpoint.

However, in the above case I don't think it is obvious that you want to 
IP-tunnel the packet to N.  You might just want to tunnel it around the 
non-MPLS node.   In that case, the tunnel's receive endpoint can still 
be regarded as a remote label distribution peer of the transmit 
endpoint, but the receive endpoint is not N.

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 11 Apr 2016 14:58:32 -0400

>> [Eric] It would be somewhat unusual to have an IGP domain in which some nodes support MPLS and some don't.
> [Uma] May be true with non-SR and traditional  MPLS.
Interesting.  But I'm not sure which of two scenarios you are describing:

1. There is always an MPLS path from ingress to egress, but the shortest 
path may not consist entirely of MPLS-capable nodes.

2. There isn't always an MPLS path from ingress to egress.  So if the 
ingress creates an MPLS packet, some intermediate node may need to 
re-encapsulate the packet  in IP, in order to get the packet delivered 
to the egress node.

Or is the scenario different from either of these two?

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 11 Apr 2016 21:45:08 +0000

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Eric C Rosen [mailto:[email-masked]] 
Sent: Monday, April 11, 2016 11:59 AM
To: Uma Chunduri; Xuxiaohu; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

1. There is always an MPLS path from ingress to egress, but the shortest path may not consist entirely of MPLS-capable nodes.

2. There isn't always an MPLS path from ingress to egress.  So if the ingress creates an MPLS packet, some intermediate node may need to re-encapsulate the packet  in IP, in order to get the packet delivered to the egress node.

[Uma]: I was describing more of #2. However #1 is one of the cases. 
              In #2 as the shortest path neighbor doesn't support SR (and no outgoing LDP/RSVP label) and it recognizes the same, it encapsulates in IP or 
              as per the  egress node N's tunnel de-capsulation capabilities. 
              There is no additional computation required here and  its still shortest path towards egress but not labeled.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 11 Apr 2016 21:46:31 +0000

Hi Eric,

Quick  response  In-line [Uma]:

--
Uma C.

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Monday, April 11, 2016 11:51 AM
To: Xuxiaohu; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

> [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR receiving the above MPLS packet with top label…

Yes, in this case, the tunnel's receive endpoint can be regarded as a remote label distribution peer of the tunnel's  transmit endpoint.

However, in the above case I don't think it is obvious that you want to IP-tunnel the packet to N.  
You might just want to tunnel it around the 
non-MPLS node.   In that case, the tunnel's receive endpoint can still 
be regarded as a remote label distribution peer of the transmit endpoint, but the receive endpoint is not N.

[Uma]:  Sure, this can be done; if at all if there is a shortest path node towards N (supporting MPLS/SR) and if we can tunnel to that node yes, packet can be delivered to N eventually.
               However, this involves (additional computation/adjustment) computation by all the boarder nodes to deliver it to the shortest SR node towards N.
               In that case, actually I would have expected operator to put that additional node Label as the top label instead of N. If the former has to happen operator has to 
               exercise how this should happen through a knob ..(apart from the additional work on the boarder node).

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 12 Apr 2016 00:23:01 +0000

> On Apr 7, 2016, at 6:39 PM, Xuxiaohu <[email-masked]> wrote:
> 

Is this really a “remote label distribution peer”? Or a local one by way of the forwarding adjacency of an IP Tunnel as a logical MPLS-enabled interface (towards N or bypassing the old router)?

Thanks,

— Carlos.

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 12 Apr 2016 10:07:50 +0000

> From: Uma Chunduri [mailto:[email-masked]]
> Sent: Tuesday, April 12, 2016 5:47 AM
> To: Eric C Rosen; Xuxiaohu; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] Clarification on the motivation of
> draft-xu-spring-islands-connection-over-ip-05
> 
> Hi Eric,
> 
> Subject: Re: [mpls] Clarification on the motivation of
> draft-xu-spring-islands-connection-over-ip-05
> 
> > [Xiaohu] The FEC associated the above label L is the /32 or 128/ prefix of node
> N. When the IGP next-hop towards that FEC is a non-MPLS node, the LSR
> receiving the above MPLS packet with top label of L is desired to forward that
> MPLS packet towards node N via an IP-based tunnel. In this case, the node N is
> the remote peer for that FEC.
> 
> Yes, in this case, the tunnel's receive endpoint can be regarded as a remote label
> distribution peer of the tunnel's  transmit endpoint.
> 
> [Uma]:  Sure, this can be done; if at all if there is a shortest path node towards
> N (supporting MPLS/SR) and if we can tunnel to that node yes, packet can be
> delivered to N eventually.
>                However, this involves (additional computation/adjustment)
> computation by all the boarder nodes to deliver it to the shortest SR node
> towards N.
>                In that case, actually I would have expected operator to put
> that additional node Label as the top label instead of N. If the former has to
> happen operator has to
>                exercise how this should happen through a knob ..(apart from
> the additional work on the boarder node).

Agree with Uma. There is no need to introduce any complexity to the SPF algorithm by taking N as the remote peer.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 12 Apr 2016 10:05:08 +0000

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, April 12, 2016 8:23 AM
To: Xuxiaohu
Cc: Eric C Rosen; [email-masked]; [email-masked]
Subject: Re: [mpls] Clarification on the motivation of draft-xu-spring-islands-connection-over-ip-05

On Apr 7, 2016, at 6:39 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:

[Xiaohu] what’s the difference between the above two?

Best regards,
Xiaohu

Thanks,

— Carlos.

Best regards,
Xiaohu