Subject: Re: [spring] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

From: Jeff Tantsura <[email-masked]>
Date: Fri, 16 Jan 2015 15:09:38 +0000

Hi Robin,

Your understanding of interworking on Independent and Ordered control is incorrect.
Please read RFC5036  sections 2.6.1.1. Independent Label Distribution Control and 2.6.1.2. Ordered Label Distribution Control.

In the case described S13 (Independent) will distribute mapping for S14 without need to receive it from downstream node (that’s why it is called Independent). S12(Ordered) will then send it to its upstream

The general issue with Independent is described in section 2.6.1.1. Independent Label Distribution Control and is not SR related.
“A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.”

Hope this clarifies,

Cheers,
Jeff

From: Lizhenbin <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 15, 2015 at 5:12 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [spring] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi all authors of segment routing,

When we did research on segment routing and found some new issues. Could you help clarify if the analysis is right and

how will they be taken into account in the design of SR.

This is the first issue.

                           (Non-SR)
  S11-----------S12----------S13---------S14
   |             |            |           |
   |             |            |           |
   |             |            |           |
  S21-----------S22----------S23---------S24

As above topoloby, there are 8 nodes and assume all the metics of the links are 1 and VPNs are deployed
on S11/S21/S14/S24.

If LDP is used as the tunnel for VPN on S11/S14, since LDP can support the ordered mode. The LSP for the S14 will be
setup as the order S14->S13->S12->S11 for distribution of label mapping. And the shortest path for routes
to S14 is also S11->S12->S13->S14. So the end-to-end LSP to S14 is setup. If one node (e.g. S13) does not
support LDP, according to LDP ordered mode, the end-to-end LSP cannot setup since S12 does not receive the label
mapping from the exact nexthop of the route, S13 and it will not distribute the label mapping to S11. And the

result is that the VPN on S11 cannot take the LSP since the LSP cannot setup on S11.

If SR-BE path is used as the tunnel for VPN on S11/S14 and assume the S13 cannot support the SR, according to my
understanding, there will be an SR-BE path for the destination S14 which is interrupted at S12. This is similar as
the independent mode of LDP. If this VPN takes this SR-BE Path at S11, the VPN traffic will be dropped at S12.

If the analysis is right. I have two questions:
1. How will SR avoid such risk? Some enhancement on SR or just leave it to the local implmentation (For example,
LSP ping is firstly used to check the connectivity)?
2. Assume LDP is already deployed on all nodes in the network to bear VPN traffic. When SR-BE path is adopted in the
network to replace LDP LSP, since there is the possible risk proposed by interrupted SR-BE path and I do not think it

is impossible to carefully determine the upgraded nodes. So the only choice is to upgrade all nodes to support SR all

at once. is that right that the incremental deployment of SR in such scenario is difficult to adopt?

Regards,

Zhenbin(Robin)