Subject: [spring] Why connecting SPRING islands over IP//FWD: New Version Notification for draft-xu-spring-islands-connection-over-ip-00.txt

From: Xuxiaohu <[email-masked]>
Date: Tue, 18 Feb 2014 02:44:51 +0000

Hi SPRINGer,

As stated in the SR use case draft (http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases), service chain is one of the most important use cases for SPRING. In this particular use case, it seems that it's only necessary to enable SR capability on service nodes, in addition to ingress and egress nodes. In other word, it seems no need for intermediate nodes to enable SR capability at all. In this way, the deployment cost would be greatly reduced since the intermediate nodes don't need to be upgraded anymore. To achieve the above goal, it only requires a SR node to encapsulate the to-be-forwarded MPLS packets with an IP tunnel header(e.g., GRE tunnel) and then send the encapsulated packets to the next-hop SR node which is identified by the top label, once the direct IGP next-hop node is non-SR-capable. As for what tunnel type is to be used, it could either be manually configured on the tunnel ingress nodes or dynamically advertised by the tunnel egress nodes. 

Since interoperability with non-SPRING nodes have been recognized as a must by the SPRING problem statement draft, in addition to the LDP-SR-interoperation, how to connect SPRING islands (or nodes) over IP should be considered as a useful interoperation option as well, IMHO.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2014年2月8日 11:45
> 收件人: Siva Sivabalan; Siva Sivabalan; Xuxiaohu; Xuxiaohu
> 主题: New Version Notification for
> draft-xu-spring-islands-connection-over-ip-00.txt
> 
> 
> A new version of I-D, draft-xu-spring-islands-connection-over-ip-00.txt
> has been successfully submitted by Xiaohu Xu and posted to the IETF repository.
> 
> Name:		draft-xu-spring-islands-connection-over-ip
> Revision:	00
> Title:		Connecting SPRING Islands over IP Networks
> Document date:	2014-02-08
> Group:		Individual Submission
> Pages:		4
> URL:
> http://www.ietf.org/internet-drafts/draft-xu-spring-islands-connection-over-ip-
> 00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-xu-spring-islands-connection-over-ip/
> Htmlized:
> http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00
> 
> 
> Abstract:
>    Segment Routing (SR) architecture [SR-ARCH] introduces a new MPLS
>    paradigm in which a sender of a packet is allowed to partially or
>    completely specify the route the packet takes through the network by
>    using stacked MPLS labels. The current SR architecture requires an
>    end-to-end MPLS Label Switched Path (LSP) between any two SR-enabled
>    routers (e.g., two adjacent hops of a given explicit path). In order
>    to enable SR to be deployed even when there are non-MPLS routers
>    along the path between two SR-enabled routers, it is desirable to
>    have an alternative, which allows the use of IP-based tunnels (e.g.,
>    GRE tunnels) to connect two SR-enabled routers. This document
>    describes a mechanism for such usage.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Feb 2014 10:40:37 +0100

Hi Xu,

You wrote:

   The current SR architecture requires an end-to-end MPLS Label
   Switched Path (LSP) between any two SR-enabled routers (e.g., any two
   adjacent hops of a given explicit path).

But this is not quite right. SR architecture has been very clear to
support operation over both: non MPLS pure IP networks as well as MPLS
networks.

Specifically the architecture draft says:

   Segment Routing can also be applied to IPv6 with a new type of
   routing extension header.

So at least one deployment model is to use new IPv6 header with
additional extension headers. The dst address in the IPv6 packet can
be original (only extension headers are inserted) or new one added at
ingress which would exactly provide the functionality you describe.

In other words I am not sure there are use cases to have partial MPLS
deployments at all. You either run MPLS signalling protocol and MPLS
data plane or just operate real IP dual stack or IPv6 only network.

Cheers,
R.

On Tue, Feb 18, 2014 at 3:44 AM, Xuxiaohu <[email-masked]> wrote:
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 18 Feb 2014 10:02:39 +0000

Hi Robert,

> -----邮件原件-----
> 发件人: spring [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2014年2月18日 17:41
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> 主题: Re: [spring] Why connecting SPRING islands over IP//FWD: New Version
> Notification for draft-xu-spring-islands-connection-over-ip-00.txt
> 
> Hi Xu,
> 
> You wrote:
> 
> But this is not quite right. SR architecture has been very clear to support
> operation over both: non MPLS pure IP networks as well as MPLS networks.
> 
> So at least one deployment model is to use new IPv6 header with additional
> extension headers. The dst address in the IPv6 packet can be original (only
> extension headers are inserted) or new one added at ingress which would
> exactly provide the functionality you describe.
> 
> deployments at all. You either run MPLS signalling protocol and MPLS data plane
> or just operate real IP dual stack or IPv6 only network.

Take the service chain use case as an example, if operators want to use the segment routing technology to define the service chain path, they would have to upgrade all the routers within their networks according to the current SR architecture. That would be costly. With the mechanism proposed in this draft, they just need to upgrade the service nodes and ingress/egress nodes to support SR capability.

Best regards,
Xiaohu 

> > As stated in the SR use case draft
> (http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-cases),
> service chain is one of the most important use cases for SPRING. In this
> particular use case, it seems that it's only necessary to enable SR capability on
> service nodes, in addition to ingress and egress nodes. In other word, it seems
> no need for intermediate nodes to enable SR capability at all. In this way, the
> deployment cost would be greatly reduced since the intermediate nodes don't
> need to be upgraded anymore. To achieve the above goal, it only requires a SR
> node to encapsulate the to-be-forwarded MPLS packets with an IP tunnel
> header(e.g., GRE tunnel) and then send the encapsulated packets to the
> next-hop SR node which is identified by the top label, once the direct IGP
> next-hop node is non-SR-capable. As for what tunnel type is to be used, it could
> either be manually configured on the tunnel ingress nodes or dynamically
> advertised by the tunnel egress nodes.
> >
> > Since interoperability with non-SPRING nodes have been recognized as a must
> by the SPRING problem statement draft, in addition to the
> LDP-SR-interoperation, how to connect SPRING islands (or nodes) over IP should
> be considered as a useful interoperation option as well, IMHO.
> >
> > Best regards,
> > Xiaohu
> >
> >
> > > -----邮件原件-----
> > > A new version of I-D,
> > > Please note that it may take a couple of minutes from the time of
> > > submission until the htmlized version and diff are available at tools.ietf.org.
> > >
> > > The IETF Secretariat
> >

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 18 Feb 2014 14:21:24 +0100

Hi Xu,

> Take the service chain use case as an example, if operators want to use the segment routing technology to define the service chain path, they would have to upgrade all the routers within their networks according to the current SR architecture.

That is not correct. Using even MPLS/label based Segment Routing does
not require any touch to existing MPLS (for example: LDP) nodes.

In fact that's main purpose of Hannes draft:
https://tools.ietf.org/html/draft-gredler-spring-mpls-02

> That would be costly. With the mechanism proposed in this draft, they just need to upgrade the service nodes and ingress/egress nodes to support SR capability.

That's already possible today both with MPLS and with pure IP
networks. Notice that all protocol extentions allow for both labels as
well as IP addresses to be SIDs. As described earlier IPv6 has such
option day one and SR architecture clearly allows that.

I agree that IPv6 draft is not published yet, but should be in not so
distant future ...

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Feb 2014 02:14:22 +0000

Hi Robert,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
> 发送时间: 2014年2月18日 21:21
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> > Take the service chain use case as an example, if operators want to use the
> segment routing technology to define the service chain path, they would have to
> upgrade all the routers within their networks according to the current SR
> architecture.
> 
> That is not correct. Using even MPLS/label based Segment Routing does not
> require any touch to existing MPLS (for example: LDP) nodes.

Did you mean enabling SR capability on service nodes and ingress/egress nodes while enabling LDP on all nodes? If so, does it seem a bit heavyweight compared to the deployment model that has been proposed in this draft?

> https://tools.ietf.org/html/draft-gredler-spring-mpls-02

Or did you mean just enabling LDP and T-LDP for Explicitly Routed Tunnels by Stacked LSPs just as what the following quoted text has demonstrated? If so, I agree that it may not require any change to the existing LDP/MPLS nodes. However, wouldn't you believe it's a bit more heavyweight from the network operation perspective?

   At least in principle, these label bindings could be obtain by such
   already defined label distribution protocols as LDP (to be more
   precise, targeted LDP if the two routers are more than one hop away
   from each other). E.g., if one uses targeted LDP, then R0 would need
   to dynamically establish and maintain a targeted LDP session with R3
   and another targeted LDP session with R2 (R0 would maintain a
   "vanilla" LDP session with R1). Using these LDP sessions R0 would
   obtain from R3 label binding for LSP4, from R2 label binding for
   LSP3, and from R1 label binding for LSP2. Note that obtaining such
   labels bindings with targeted LDP may also require defining a new FEC
   to be used by targeted LDP.

> > That would be costly. With the mechanism proposed in this draft, they just
> need to upgrade the service nodes and ingress/egress nodes to support SR
> capability.
> 
> That's already possible today both with MPLS and with pure IP networks. Notice
> that all protocol extentions allow for both labels as well as IP addresses to be
> SIDs. As described earlier IPv6 has such option day one and SR architecture
> clearly allows that.

Where does it said that IP addresses would be used as SIDs?

Best regards,
Xiaohu

> I agree that IPv6 draft is not published yet, but should be in not so distant
> future ...

> >> (http://tools.ietf.org/html/draft-filsfils-rtgwg-segment-routing-use-
> >> cases), service chain is one of the most important use cases for
> >> SPRING. In this particular use case, it seems that it's only
> >> necessary to enable SR capability on service nodes, in addition to
> >> ingress and egress nodes. In other word, it seems no need for
> >> intermediate nodes to enable SR capability at all. In this way, the
> >> deployment cost would be greatly reduced since the intermediate nodes
> >> don't need to be upgraded anymore. To achieve the above goal, it only
> >> requires a SR node to encapsulate the to-be-forwarded MPLS packets
> >> with an IP tunnel header(e.g., GRE tunnel) and then send the
> >> encapsulated packets to the next-hop SR node which is identified by
> >> the top label, once the direct IGP next-hop node is non-SR-capable.
> >> As for what tunnel type is to be used, it could either be manually
> >> configured on the tunnel ingress nodes or dynamically advertised by the
> tunnel egress nodes.
> >> >
> >> LDP-SR-interoperation, how to connect SPRING islands (or nodes) over
> >> IP should be considered as a useful interoperation option as well, IMHO.
> >> >
> >> > Best regards,
> >> > Xiaohu
> >> >
> >> >
> >> > > -----邮件原件-----
> >> > > has been successfully submitted by Xiaohu Xu and posted to the
> >> > > IETF
> >> repository.
> >> > >
> >> > > http://www.ietf.org/internet-drafts/draft-xu-spring-islands-conne
> >> > > cti
> >> > > on-over-ip-
> >> > > 00.txt
> >> > > Status:
> >> > > https://datatracker.ietf.org/doc/draft-xu-spring-islands-connecti
> >> > > on-
> >> > > over-ip/
> >> > > Htmlized:
> >> > > http://tools.ietf.org/html/draft-xu-spring-islands-connection-ove
> >> > > r-i
> >> > > p-00
> >> > >
> >> > >
> >> > > Abstract:

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 19 Feb 2014 10:41:39 +0100

Hi Xu,

> Where does it said that IP addresses would be used as SIDs?

I think you may be mixing tunnel endpoint with SID. SID in all specs
is defined as 4 octet where if label is used 20 bits are significant
and if integer is used all 32 bits are significant.

Example of ISIS encoding:

2.1.  SID/Label Sub-TLV

   The SID/Label Sub-TLV is present in multiple Sub-TLVs defined in this
   document and contains a SID or a MPLS Label.  The SID/Label Sub-TLV
   has the following format:

Previdi, et al.          Expires August 17, 2014                [Page 4]
Internet-Draft    IS-IS Extensions for Segment Routing     February 2014

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          SID/Label (variable)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where:

      Type: 1

      Length: variable (3 or 4)

      SID/Label: if length is set to 3 then the 20 rightmost bits
      represent a MPLS label.  If length is 4 then the value represents
      a 32 bits SID.

So in pure IPv6 env you can optionally encapsulate with your
destination endpoint and just insert few extensions headers of 32 bit
integer being SID.

No MPLS at all and no upgrade to any "transit/P" routers needed at all.

In fact that would be the most natural deployment case.

To your other point of heavy weight to enable LDP I would point out
that anyone I know who would use SID as 20 bit label already has
running LDP in the network so zero new deployment would be needed in
transit/P nodes anyway.

Your case it also valid -  I am not saying it is not - to use GRE
between segment verticies. However I struggle how superior it is
against IPv6 SR if each node will need to encapsulate and decapsulate
again. You can do that today without any segment routing - and if we
take simple example of L3VPNs this all works today by few basic RT
import/export rules.

Cheers,
R.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 19 Feb 2014 10:05:29 +0000

Hi Robert,

> 发送时间: 2014年2月19日 17:42
> 主题: Re: [spring] 答复: Why connecting SPRING islands over IP//FWD: New
> Version Notification for draft-xu-spring-islands-connection-over-ip-00.txt
> 
> Hi Xu,
> 
> I think you may be mixing tunnel endpoint with SID. SID in all specs is defined as
> 4 octet where if label is used 20 bits are significant and if integer is used all 32
> bits are significant.
> 
> So in pure IPv6 env you can optionally encapsulate with your destination
> endpoint and just insert few extensions headers of 32 bit integer being SID.
> 

Perfect. Even in the case where a MPLS label stack is used to indicate an explicit path, we could achieve the same goal by using the IP-based tunnel between any adjacent SR hop of that explicit route, in both IPv4 and IPv6 environments.

> To your other point of heavy weight to enable LDP I would point out that anyone
> I know who would use SID as 20 bit label already has running LDP in the
> network so zero new deployment would be needed in transit/P nodes anyway.
> 
> Your case it also valid -  I am not saying it is not - to use GRE between segment
> verticies. However I struggle how superior it is against IPv6 SR if each node will
> need to encapsulate and decapsulate again. You can do that today without any

IMO, the MPLS label stack could be used to indicate an explicit path for both IPv4 SR and IPv6 SR.

Best regards,
Xiaohu

> segment routing - and if we take simple example of L3VPNs this all works today
> by few basic RT import/export rules.
> 
> Cheers,
> R.
>