Hi Bruno,

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



Regards,

Robin



________________________________
发件人: [email protected] [[email protected]]
发送时间: 2015年1月16日 15:55
收件人: DECRAENE Bruno IMT/OLN; Lizhenbin; [email protected]
主题: 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 protected]] On Behalf Of 
[email protected]
Sent: Thursday, January 15, 2015 4:57 PM
[…]



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.

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

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





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.

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





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

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

_________________________________________________________________________________________________________________________

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.

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to