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

From: Lizhenbin <[email-masked]>
Date: Thu, 15 Jan 2015 13:12:18 +0000

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)

---

From: <[email-masked]>
Date: Thu, 15 Jan 2015 15:56:59 +0000

Hi Robin,

Thanks for your interest on SR/SPRING.
Please see inline. [Bruno]

From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Thursday, January 15, 2015 2:12 PM
To: [email-masked]
Subject: [spring] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

This is the first issue.

                           (Non-SR)

[Bruno]

My understanding of your case is the following, please correct me if I'm wrong:

There is no SPRING/SR. All nodes support LDP. S11, S12, S14 use ordered mode. S13 use independent mode.

First, such cases happen today in multiple vendor networks since different implementation used different options.

Then, I believe that your understanding of LDP independant mode  is incorrect. In independent mode, S13 always advertises the S14 FEC to its neighbor, even if it don't gets a label mapping from its downstream S14. This FEC is then propagated to S11 in ordered mode.

As a result, S11 gets a label for S14 and will use S14 for the VPN. However in the forwarding plane the traffic will be dropped on S13.

[Bruno] A priori, I could see 3 answers

-a- I guess one could use IGP multi-topology to handle a different topology between the IP and the MPLS one. This is similar to IPv6 introduction in a IPv4 network.

-b- Another option is to enable interworking between LDP and SR/SPRING to handle such incremental deployment. Please see the following draft for an introduction on this interworking: https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop-02 Comments are welcomed as I agree with you that's an important topic for brownfield incremental deployment

-c- Another option is to incrementally deploy SR in addition to LDP and to prefer LDP for end to end LSP (using administrative distance). Then it's up to each SR application to see how much they can take benefit of partial SR deployment. e.g. FRR (TI-LFA, RLFA or DLFA) may/should be able to benefit from partial deployment.

FYI, as of today/myself I say that "b" is required and "c" is nice to have.

is impossible to carefully determine the upgraded nodes.

[Bruno] I'm not sure to correctly understand your last sentence. Within an AS (well area/level) It is possible to identify nodes which are SR/SPRING compliant (or non compliant) as they advertise this in the link state IGP.

So the only choice is to upgrade all nodes to support SR all at once.

[Bruno] No.

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

Regards,

Zhenbin(Robin)

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Fri, 16 Jan 2015 07:55:34 +0000

1 correction inlined. [Bruno2]

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 15, 2015 4:57 PM
[...]

This is the first issue.

                           (Non-SR)

[Bruno]

[Bruno2] I withdraw my last sentence. In this fist cast, traffic is not dropped. It works fine. We only lose the propagation of LDP FEC status in the control plane.

---

From: Lizhenbin <[email-masked]>
Date: Sun, 18 Jan 2015 05:07:41 +0000

Hi Bruno,

Please refer to my comments inline identified by '[Robin]'.

Regards,

Robin

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2015年1月16日 15:55
收件人: DECRAENE Bruno IMT/OLN; Lizhenbin; [email-masked]
主题: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

[…]

This is the first issue.

                           (Non-SR)

[Bruno]

My understanding of your case is the following, please correct me if I’m wrong:

[Robin] I don't mean S13 use independent mode. I mean S13 doesn't support LDP. That is S13 is a non-LDP node.

Then, I believe that your understanding of LDP independant mode  is incorrect. In independent mode, S13 always advertises the S14 FEC to its neighbor, even if it don’t gets a label mapping from its downstream S14. This FEC is then propagated to S11 in ordered mode.

[Robin] Please rethink the use case taking into account that S13 cannot supported in LDP. Since S13 cannot send the label mapping to S12, this means S12 cannot receive the label mapping from its exact nexthop for the prefix S14, S12 will not send the label mapping for S14  to S11.

[Robin] I could not understand your point. In fact, this case is simple. It just explain that if the ordered LDP is incrementally deployed, the traffic can be dropped at the ingress node without leaking the traffic into the network.

---

From: Lizhenbin <[email-masked]>
Date: Sun, 18 Jan 2015 05:09:38 +0000

________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2015年1月15日 23:56
收件人: Lizhenbin; [email-masked]
主题: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi Robin,

This is the first issue.

                           (Non-SR)

[Bruno]

-b- Another option is to enable interworking between LDP and SR/SPRING to handle such incremental deployment. Please see the following draft for an introduction on this interworking: https://tools.ietf.org/html/draft-filsfils-spring-segment-routing-ldp-interop-02 Comments are welcomed as I agree with you that’s an important topic for brownfield incremental deployment

-c- Another option is to incrementally deploy SR in addition to LDP and to prefer LDP for end to end LSP (using administrative distance). Then it’s up to each SR application to see how much they can take benefit of partial SR deployment. e.g. FRR (TI-LFA, RLFA or DLFA) may/should be able to benefit from partial deployment.

FYI, as of today/myself I say that “b” is required and “c” is nice to have.

[Bruno] I’m not sure to correctly understand your last sentence. Within an AS (well area/level) It is possible to identify nodes which are SR/SPRING compliant (or non compliant) as they advertise this in the link state IGP.

[Bruno] No.

Regards,

Zhenbin(Robin)

---

From: Lizhenbin <[email-masked]>
Date: Sun, 18 Jan 2015 05:40:41 +0000

Hi Bruno,

For LDP, there are two LDP control modes:

-- Ordered mode: Depend on the egress and the downstream node

-- Independent mode: Depend on the downstream node.

In fact, SR is based on IGP and introduces one totally different mode which I called as flooding mode.

-- Flooding mode: Depend the node's self

Comparing the there mode, the flooding mode is more independent. This means it is the essiest one to

set up the interrupted LSP and leak the useless traffic into the network which will have negative effect

on the normal traffic in the network.

Best Regards,

Robin

Hi Robin,

This is the first issue.

                           (Non-SR)

[Bruno]

[Robin] It has explained in the previous mail. Please rethink the case that S13 does not support LDP instead of that S13 support independent mode.

[Robin] I do not think multi-topoloty and SR-LDP interop will propose can not solved the issued. But the price is high. In fact, I have read the draft. But I do not think think it is an easy work according to the past experience in the MPLS world. I will explain the possible work should be taken into account in the subsequent comments. A small example, SR claimed it can replace the IGP-LDP sync. But as a developer, I am sure that the effort of implementation of SR-LDP interop is much more than IGP-LDP sync. Can I say that in fact SR does not save our effort, but make more trouble?

[Robin] The difficulty is that the ingress node cannot determine if the SR-BE path is end-to-end without extra methods which is unnecessary for the LDP already deployed in the whole network.

[Robin] I agree your proposed the incremental deployment method by IGP extension to identifed the SR-node. This is not what my objective. My case is to show that the scope of end-to-end LSP and the scope of the SR nodes is different. The incremental deployment of SR cause the issue for the end-to-end LSP.

[Bruno] No.

[Robin] I can agree you that it may be necessary. But more details be taken into account and the price may be high and .

Regards,

Zhenbin(Robin)

---

From: <[email-masked]>
Date: Sun, 18 Jan 2015 09:34:17 +0000

Hi Robin,

Please refer to my comments inline identified by '[Bruno2]'.

Regards,
Bruno

From: Lizhenbin [mailto:[email-masked]]
Sent: Sunday, January 18, 2015 6:08 AM
To: DECRAENE Bruno IMT/OLN; [email-masked]
Subject: ??: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi Bruno,

Regards,

Robin

________________________________
发件人: [email-masked]<mailto:[email-masked]> [[email-masked]]
发送时间: 2015年1月16日 15:55
收件人: DECRAENE Bruno IMT/OLN; Lizhenbin; [email-masked]<mailto:[email-masked]>
主题: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment
1 correction inlined. [Bruno2]

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, January 15, 2015 4:57 PM
[…]

This is the first issue.

                           (Non-SR)

[Bruno]

[Bruno2] ok. In this case you are right that the LSP is interrupted and the control plane vision is different between ordered and independent mode. This is a point which is specific to LDP and 15 years old, and not related to SPRING.

/Bruno

Thank you.

---

From: <[email-masked]>
Date: Sun, 18 Jan 2015 10:13:00 +0000

Hi Robin,

Please see inline [Bruno2]

Regards,
Bruno

From: Lizhenbin [mailto:[email-masked]]
Sent: Sunday, January 18, 2015 6:41 AM
To: DECRAENE Bruno IMT/OLN; [email-masked]
Subject: ??: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi Bruno,

[Bruno2] I’m not sure to see what you mean by “depend”.

In LDP ordered mode, there is a signaling end to end from the egress to the ingress, roughly a la “distance vector”.

In LDP independent mode, the signaling is limited to be 2 adjacent nodes (me, my downstream). So roughly no signaling.

In SPRING, the Link State paradigm is used. You know the status of the egress and all the links  & nodes.

[Bruno2] I disagree. You have the link state vision of the whole SPRING network. That’s the “mode” which provides the more information. Specifically,

 You know that the egress is “up” and that all nodes on the way are also “up” and ready (I do mean from a SPRING/MPLS standpoint).

Obviously, this is a control plan vision only. If you want to check the FIB, you will need to test it (e.g. LSP Ping)

Best Regards,

Robin

________________________________
发件人: [email-masked]<mailto:[email-masked]> [[email-masked]]
发送时间: 2015年1月15日 23:56
收件人: Lizhenbin; [email-masked]<mailto:[email-masked]>
主题: RE: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment
Hi Robin,

From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Thursday, January 15, 2015 2:12 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

This is the first issue.

                           (Non-SR)

[Bruno]

[Robin] I do not think multi-topoloty and SR-LDP interop will propose can not solved the issued.

[Bruno2] Not sure why you use double negation. But in short, you also believe this should work.

[Robin]

But the price is high. In fact, I have read the draft. But I do not think think it is an easy work according to the past experience in the MPLS world. I will explain the possible work should be taken into account in the subsequent comments. A small example, SR claimed it can replace the IGP-LDP sync. But as a developer, I am sure that the effort of implementation of SR-LDP interop is much more than IGP-LDP sync. Can I say that in fact SR does not save our effort, but make more trouble?

[Bruno2] The use of SR-LDP interwork allows incremental deployment of SR with incremental benefit but is indeed an additional work. It is only needed in a multi-vendor/plateform network when all nodes do not support SR, for a limited duration. It’s not long term feature. If you ask me, I would rather not have to use it, but it depends on the willing of vendors to implement the required IGP sub-TLVs. If we all agree that implementing such sub-TLV is easier and better (or if you assume mono vendor deployment, which I don’t) we won’t need to deploy/implement LDP-SPRING interworking. This is a roadmap versus deployment date issue, so a bit out of scope of this mailing list. However, from the mailing list standpoint, the point is that this can be done (specified and implemented)

[Bruno2] Again, No. please see https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-03#section-3 The ingress knows, within its IGP area/level, all nodes which supports SPRING or not. This includes nodes on the SPT to the egress.

 [Bruno2] I’m not sure to see your point. In particular by “end-to-end” to you mean within an area/level, or across ASes? Because as SPRING uses the IGP, IGP frontiers makes a difference. Can you please rephrase or bring an non-working example?

[Bruno] No.

Regards,

Zhenbin(Robin)

Thank you.

---

From: Lizhenbin <[email-masked]>
Date: Tue, 20 Jan 2015 06:42:19 +0000

Hi Bruno,

Please refer to my inline comments identified with '[Robin]'.

Regards,

Robin

发送时间: 2015年1月18日 18:13

Hi Robin,

Regards,
Bruno

Hi Bruno,

[Robin]

1. The 'depend' means the label binding for the nodes in segment routing is stable, after the label binding are flooded, for

every nodes in the network,  once there are the routes to the destination nodes address, the ingress LSP can be setup to be used

for VPN, etc. For LDP independent, even if the route is available, it has to wait for the label mapping from the downstream to

setup the ingress LDP to be used for VPN, etc.

2. I am not sure what's the link state paradigm you mean? For LDP, it depends on IGP, it can also use the link state paradigm.

The only difference is that the segment routing can use it conveniently since the label binding coexists with link state paradigm.

[Robin]

I understand your point about the control plane solution to some extent. In fact, I have also thought about solutions for the the possible

interruption issues for SR-BE path. As to your suggested solution of the control plane, it can be done, but it has been the end-to-end path

calculation like TE instead of the traditional route path calculation.

Best Regards,

Robin

This is the first issue.

                           (Non-SR)

[Bruno]

[Robin]

[Bruno] No.

Regards,

Zhenbin(Robin)

Thank you.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 29 Jan 2015 04:15:52 +0000

Hi Robin,

>As to your suggested solution of the control plane, it can be done, but it has been the end-to-end path

>calculation like TE instead of the traditional route path calculation.

Gone through the exchange below. If I understand correct –
IMO, it’s a deployment issue if S13 doesn’t support neither SR nor LDP. If LDP is supported stitching should happen on S12 from SR to LDP.
Now, ingress node need not have an idea of the stitching  even if S14 is non-SR , as long as it’s label/index is advertised through binding SIDs.

The missing point AFAICT is on “explanation” of processing of binding SIDs (for mapping server functionality) at ingress node  -
i.e., not only S12 which realizes S13 (non-SR capable and do the right thing) but S11 should also compute and add
LSP for the binding SID for S14 index with best path next-hop  (which is an SR node).

Is your issues addressed with this?
--
Uma C.

From: spring [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Monday, January 19, 2015 10:42 PM
To: [email-masked]; [email-masked]
Subject: [spring] 答复: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi Bruno,

Regards,

Robin

Regards,
Bruno

From: Lizhenbin [mailto:[email-masked]]
Sent: Sunday, January 18, 2015 6:41 AM
To: DECRAENE Bruno IMT/OLN; [email-masked]<mailto:[email-masked]>
Subject: ??: New Comments on Segment Routing(1): Challenge of Ordered mode for SR-BE Path and Incremental Deployment

Hi Bruno,

[Robin]

[Robin]

Best Regards,

Robin

This is the first issue.

                           (Non-SR)

[Bruno]

[Robin]

[Bruno] No.

Regards,

Zhenbin(Robin)

Thank you.

Thank you.