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

[Joel Halpern <[e-mail]>]

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 doesn't 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 <https://aka.ms/AAb9ysg>
>
>             ------------------------------------------------------------------------
>
>             *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 [e-mail]
>