[spring] Re: My question at the mikeaboutdraft-dong-spring-srv6-inter-layer-programming

[韩柳燕 <[e-mail]>]

Hi Joel,

 

Thank you for your question.

 

The underlay networks, such as optical OTN network or MTN network, support periodic OAM transport and detection. OAM detection can determine whether the ODUk or MTN link is up. If there is a fault, an alarm will be reported and protection switching will be triggered.



Best regards,

Liuyan



 ----邮件原文----发件人：Joel Halpern  <[e-mail]>收件人："韩柳燕" <[e-mail]>,draft-dong-spring-sr <[e-mail]>,"Alexander.Vainshtein" <[e-mail]>,"Dongjie (Jimmy)" <[e-mail]>抄　送: "[e-mail]" <[e-mail]>发送时间：2024-08-15 23:02:31主题：Re: [spring] Re: My question at the mikeaboutdraft-dong-spring-srv6-inter-layer-programming
                    Is there an assumption that some other monitoring exists so that       there is knowledge of whetehr the link is up to control       advertising the new adjacency SID?

Yours,

Joel    


On 8/15/2024 6:32 AM, 韩柳燕 wrote:    
Hi Sasha,

      

Thanks a lot for your question at the meeting and via the email         discussions.

      

I would like to add some clarifications. The new SRv6 behaviors         does not require IGP based link discovery and advertisement for         the underlay connection between the two endpoints, which is         needed for End.X behavior. It is more adaptable to the network         situation and has application advantages. Because for large         networks, the nodes at both ends may span different metropolitan         areas networks or even backbone networks, and may not be in the         same IGP domain due to the limited size of IGP. The new SRv6         behaviors in this draft do not require IGP to be enabled as the         control protocol between the two end nodes of the underlay link         and doesn39t require this link to be visible in L3 topology.

      

Best regards,

Liuyan

      

 ----邮件原文----         发件人："Dongjie \\(Jimmy\\)" <jie.dong=[e-mail]>         收件人：Alexander Vainshtein  <Alexander.Vainshtein=[e-mail]>,"[e-mail]" <[e-mail]>         抄　送: "[e-mail]" <[e-mail]>         发送时间：2024-08-05 11:38:21         主题：RE: My question at the mike aboutdraft-dong-spring-srv6-inter-layer-programming                    

Hi               Sasha, 


 


Thanks               a lot for your comments during the SPRING session and in               the follow-up mails. Please see some replies inline with               [Jie]:


 




From: Alexander                     Vainshtein                     [mailto:Alexander.Vainshtein=[e-mail]]                                         Sent: Sunday, July 28, 2024 1:05 AM                     To: Dongjie (Jimmy)                     <[e-mail]>                     [e-mail]                     Cc: [e-mail]                     Subject: Re: My question at the                     mike about                     draft-dong-spring-srv6-inter-layer-programming




 


Jie,



Lots of thanks for your email.



 


First, I would like to apologize for                 not responding to your emails earlier. 


 


[Jie]                   No problem, it is always good to know your opinion no                   matter early or late:)


 



 


I think that there is a certain                 mismatch of terminology that have resulted in                 misunderstanding.


 


[Jie]                   I also realized this, and have checked with my                   colleague who is closer to the implementation.


 



 


In my (and, AFAIK, relatively common)                 terminology frames received from a Layer 2 logical                 interface are disposed based solely in their L2 header.                 (In the case of Ethernet this would include Destination                 and Source MAC addresses  and zero, one or two VLAN tags                 - but not the "true" Ethertype that follows these tags.                 Other L2 media uses similar arrangements). I.e., the                 node that receives Ethernet frames from what it                 considers a L2 interface cannot differentiate between,                 say, IPv4, ARP,  IPv6 and MPLS.


 


[Jie]                   Agreed, although to my understanding MPLS sits between                   layer 2 and layer 3. 


 


 



It is the ability to                 differentiate between different protocols based on the                 "true" Ethertype and, say, look up the Destination IPv6                 address in the appropriate FIB (which is required for                 SRv6) that makes an interface a  L3 one from my POV.


 


[Jie]                   Agree that for an interface to process SRv6 packets,                   it needs to be associated with some L3 functionality.                   While it does not need to be a full  L3 interface                   which is visible in the routing topology. In other                   word, the L3 adjacency is better to be avoided. We can                   add some clarification in next update. 



 


 


Regarding your concern about L3                 interfaces involving adjacencies, I also think this is                 unfounded. It is quite easy to make an IGP adjacency                 unusable for normal IP forwarding by assigning maximum                 cost to the corresponding  link -but using Adj-SIDs                 allocated and advertised for such a link in SR-TE                 policies that are set up by the appropriate controller.


 


[Jie]                   The primary goal here is not about how to make an IGP                   adjacency unusable in IP routing, it is about how to                   avoid the challenge and cost of  establishing IGP                   adjacency between two remote endpoints (they can even                   belong to different IGP domains). As since the                   underlay interface and path can be created/deleted                   dynamically, adding such link using Adj-SIDs to IGP                   would also impact the protocol stability. 


 


Thus                   it would be beneficial to distinguish it from the L3                   Adj-SIDs/End.X SIDs in SPRING, and its advertisement                   can also be separate from the control  plane                   mechanisms for Adj-SIDs/End.X SIDs.


 


Hope                   this helps to clarify the intent of this effort. 


 


Best                   regards,


Jie


 



 


Hopefully these notes will be useful 



 


 


Regards,



Sasha



 


 



 


Get Outlook for Android




 



--------------------------------------------------------------------------------



From: Dongjie (Jimmy) <jie.dong=[e-mail]>                     Sent: Saturday, July 27, 2024                     7:59:30 AM                     To: Alexander Vainshtein <[e-mail]>                     [e-mail]                     <[e-mail]>                     Cc: [e-mail]                     <[e-mail]>                     Subject: [EXTERNAL] Re: My question                     at the mike about                     draft-dong-spring-srv6-inter-layer-programming



                 Hi Sasha,                                 Thanks for your question at the mic. Please see some                 replies inline:                                 ________________________________________                 From: Alexander Vainshtein <Alexander.Vainshtein=[e-mail]>                 Sent: Saturday, July 27, 2024 5:27                 To: [e-mail]                 Cc: [e-mail]                 Subject: [spring] My question at the mike about                 draft-dong-spring-srv6-inter-layer-programming                                 Hi all,                 Just repeating the question about the draft<https://datatracker.ietf.org/doc/html/draft-dong-spring-srv6-inter-layer-programming-08>                 I’ve asked at he mike  at the SPRING WG session today.                                                 * Suppose that there is an underlay link between a pair                 of IP nodes that is not “visible in he L3 topology”. To                 me this means that there no P-capable (logical)                 interfaces associated with the endpoints of this                 underlay link                                 [Jie] The interface of the underlay link is not                 L3-capable, while it still can have some packet                 processing capability. You may consider it as a layer-2                 logical interface.                                                 * Suppose further that one of these nodes (the upstream                 one) allocates and advertises an SID with End.XU                 behavior for this underlay link                                 * The upstream node receives an IPv6 packets with the                 tops SRv6 SID on it being the End.XU. It strips this SID                 (this the common behavior of all End-like SIDs) and send                 the resulting IPv6 packet across the link to the                 downstream node/\.                 Now the question: How should the downstream node process                 the received packet if its local endpoint of the undelay                 link s not associated with an IP-capable logical                 interface?                                 [Jie] Similar to what I said above, the receiving                 interface is not L3-capable, while it can receive and                 process the packet properly in layer-2, the inner L3                 packet header can be processed by the node.                                                 If the endpoints of the underlay ink are associated with                 L3 interfaces in both nodes, the link becomes visible in                 L3 topology, and a regular End.X SID can be allocated                 and advertised for it.                                 [Jie] As described in the draft, making it an L3                 adjacency between the two endpoints is both challenging                 and unnecessary. And operator does not want this link to                 be visible in L3 topology. Thus regular End.X SID does                 not meet the requirement here.                                                 Hope this help to answer your question.                                 Best regards,                 Jie                                                 Hopefully this clarifies my question.                                 Regards,                 Sasha                                                                                 Disclaimer                                 This e-mail together with any attachments may contain                 information of Ribbon Communications Inc. and its                 Affiliates that is confidential and/or proprietary for                 the sole use of the intended recipient. Any review,                 disclosure, reliance or distribution by others  or                 forwarding without express permission is strictly                 prohibited. If you are not the intended recipient,                 please notify the sender immediately and then delete all                 copies, including any attachments.




      _______________________________________________
spring mailing list -- [e-mail] unsubscribe send an email to [e-mail]