[spring] 回复: Re: Call for adoption: draft-yang-spring-sid-as-source-address

[[e-mail]]

Hi Gyan,

 

We appreciate the time and effort you have put into raising these concerns. I think this draft does not have the issues that you mentioned.

 

See my comments in-line. 

 

BR,

Feng

 

发件人: Gyan Mishra <[e-mail]> 
发送时间: 2026年7月24日 8:54
收件人: Robert Raszuk <[e-mail]>
抄送: [e-mail]; spring <[e-mail]>; [e-mail]
主题: [spring] Re: Call for adoption: draft-yang-spring-sid-as-source-address

 

I do not support adoption of this draft for the reasons below:

 

Major issues with the draft below:

 

1st major issue with this subject draft is it proposes using the source IP of SRv6 tunnel to use  the service sid  endpoint behavior which is part of IP VPN VRF.  That technically won’t work as just as the loopback IGP best path selection lowest metric tie breaker next hop must be in the global table so does the source IP for the tunnel must be in the global table.  

 

[fyang] We would like to gently point out that the draft does not modify any control‑plane protocol, and the source address is not used for routing decisions. In fact, if people try a very simple test that SRv6 tunnel source address does not in global table, and that works fine. So we believe there is no requirement for the source address to be in the global table.

 

2nd major issue with this draft is that there is only one source address you can set for the SRv6 tunnel.  

 

[fyang] Single source address is the current implementation model. This is unnecessary restriction. We would respectfully note that the why not move beyond this.

 

3rd major issue is how would that work if you have many endpoint behaviors per vrf or CE Sid allocation that many Sid addresses in different vrf which would you even pick. 

 

[fyang] Selection among multiple sid can be found in the subject draft section 2. And this has been presented in spring WG meeting.

 

4th major issue that the SRv6 tunnel carries all the IP VPN  VRFs and not just the single VRF service Sid endpoint behavior that you decide to set the source address per this draft.

 

[fyang] We never propose to use same VRF sid for multipole VRF. While an SR Policy or tunnel may carry traffic from multiple VRFs, each packet is encapsulated independently:

*	Packets belonging to VRF-A use VRF-A's SID as the SA.
*	Packets belonging to VRF-B use VRF-B's SID as the SA.

 

Kind Regards 

 

Gyan

 

On Thu, Jul 23, 2026 at 4:26 PM Robert Raszuk <[e-mail] <mailto:[e-mail]> > wrote:

Hi,

 

I have read the draft and support the adoption. It is a well written and useful document. 

 

It provides a solution to data plane consistency and symmetry for ICMP. 

 

While the draft is not explicitly discussing it - it also actually solves the problem with BGP NEXT_HOP being accidentally different from Service SIDs creating all sources of bgp related issues. 

 

The service SID used as source can be in the same time advertised in BGP protocol NEXT_HOP via proper use of existing update-source knob. 

 

Kind regards,

Robert 

 

 

On Fri, Jul 10, 2026 at 2:52 PM <[e-mail] <mailto:[e-mail]> > wrote:

Dear WG,

 

This message starts a 3-week WG adoption call, ending 2026-07-31, for draft-yang-spring-sid-as-source-address-13 [1]


After review of the document, please indicate support (or not) for WG adoption of the document to the mailing list. 
Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote. 
If you are willing to work on or review the document, please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on the document. 

Thanks! 
Alvaro, Bruno, Joel

 

[1]  <https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13> https://datatracker.ietf.org/doc/html/draft-yang-spring-sid-as-source-address-13

 

____________________________________________________________________________________________________________
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 -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
spring mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>