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

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

Hi Joel,

Great suggestion and question. This part of the requirement was not expanded in the current draft. We considered that the OAM functions have been supported in the existing underlay TDM technologies and can be used to determine the availability of the underlay connection. We can add some explanations in the draft later to make it clearer.

 

Best regards,

Liuyan



 ----邮件原文----发件人：Joel Halpern  <[e-mail]>收件人："韩柳燕" <[e-mail]>,Joel Halpern  <[e-mail]>,draft-dong-spring-sr <[e-mail]>,"Alexander.Vainshtein" <[e-mail]>,"Dongjie (Jimmy)" <[e-mail]>抄　送: "[e-mail]" <[e-mail]>发送时间：2024-08-16 20:51:01主题：Re: [spring] Re: My question at themikeaboutdraft-dong-spring-srv6-inter-layer-programming
                    I may have missed it, but the draft does not seem to make clear       the requirement on the underlay to be used with this inter-layer       programming.  WHile the ddraft lists optical and MTN as examples,       it is not explicit about the restrictions that need to be met.

Yours,

Joel    

    


On 8/16/2024 6:30 AM, 韩柳燕 wrote:    
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]