Hi Gyan,
You39re right, this draft mainly aims to address scenarios where the nodes have MTN or optical channel information and are not IP routers. Transit nodes of the underlay connection only work in MTN or optical channel layer and are not IPaware. The current version have some content in IANA section for end.xu and end.bxc. Further CSID can be studied in the future. Thanks. Best regards, Liuyan ----邮件原文----发件人：Gyan Mishra <hayabusa...@gmail.com>收件人："韩柳燕" <hanliu...@chinamobile.com>抄 送: "Dongjie (Jimmy)" <jie.d...@huawei.com>,Christian Schmutzer <cschm...@cisco.com>,Ketan Talaulikar <ketant.i...@gmail.com>,draft-dong-spring-sr <draft-dong-spring-srv6-inter-layer-programm...@ietf.org>,"spring@ietf.org" <spring@ietf.org>,"Oscar Gonz醠ez de Dio" <oscar.gonzalezded...@telefonica.com>,"Alexander.Vainshtein" <alexander.vainsht...@rbbn.com>发送时间：2024-08-17 07:58:22主题：Re: Re: [spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programmingHi Liuyan Thank you for the explanation. The inter layer programming solution makes sense describing the POI and MTN use cases in section 4. So today with existing POI or MTN implementations with a hierarchical controller the IP layer is provisioned and CS-SR provides the guaranteed bandwidth per channel path protection and optical controller provisions the optical path independently of the IP controller via hierarchical top level controller. However today there is no direct communication between the IP controller and the optical controller. However it is not needed. AFAIK with POI the router with coherent pluggable or gray optics with external transponder with IP+Optical integration the router is a DWDM switch carrying the 96 wavelengths / channels with POI so the hierarchical controller is able to provide the underlay path across any legacy OTN nodes necessary steering on the photonics layer optical path to be provisioned. So we are able to provide the same outcome of steering across the underlay optical nodes that are not visible at the IP layer. Also with POI with RON “routed optical networking” the routers are IP and DWDM or ODUK channel aware and so can build the path using Adj-SID since the underlay optical nodes are IP routers as well and not hidden and are part of the IGP topology. So now with this draft the SRv6 endpoint behaviors end.xu and end.bxc the IP controller now has visibility into the OTN optical underlay topology dwdm nodes directly and the IP controller can handoff the optical provisioning to optical controller to provision the OTN steered path via the new endpoint behaviors. I would think this would be relevant to POI or MTN with legacy OTN is present where the nodes are not IP routers that are DWDM channel aware with routed optical networking where the router is a DWDM switch in which case this draft I think would not be relevant. For IANA section can you add for end.xu and end.bxc can you add Next CSID as well. Kind Regards Gyan On Fri, Aug 16, 2024 at 6:40 AM 韩柳燕 <hanliu...@chinamobile.com> wrote: Hi Gyan, Thank you for your information. In the traditional network without SID extension, optical network is invisible to IP network. Thus for the IP paths with the same source and destination, it is difficult to differentiate them and flexibly choose the different underlay optical paths. The optical controller will designate one channel for forwarding. Our SID extension solution allows for information exchange between the IP controller and the optical controller (such as through one upper controller). The optical paths can be directly selected and routed through SID even for the IP paths with the same source and destination. In addition, for multiple IP SRv6 paths, assuming that the optical layer utilizes the same ODUk channel, the optical path can be configured with the same SID, which simplifies the configuration. Best regards, Liuyan ----邮件原文----发件人：Gyan Mishra <hayabusa...@gmail.com>收件人："Dongjie (Jimmy)" <jie.d...@huawei.com>,"Christian Schmutzer (cschmutz)" <cschm...@cisco.com>抄 送: Ketan Talaulikar <ketant.i...@gmail.com>,Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org>,"draft-dong-spring-srv6-inter-layer-programm...@ietf.org" <draft-dong-spring-srv6-inter-layer-programm...@ietf.org>,"spring@ietf.org" <spring@ietf.org>,"Oscar Gonz醠ez de Dios" <oscar.gonzalezded...@telefonica.com>发送时间：2024-08-16 04:18:51主题：Re: [spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming+ Christian Schmutzer Hi Jie Most welcome. Responses in-line On Tue, Aug 6, 2024 at 4:23 AM Dongjie (Jimmy) <jie.d...@huawei.com> wrote: Hi Gyan, Thanks for your interest in this topic, and the introduction of the POI work in CCAMP is helpful. Please see some replies inline: From: Gyan Mishra [mailto:hayabusa...@gmail.com] Sent: Monday, July 29, 2024 3:50 PM To: Dongjie (Jimmy) <jie.dong=40huawei....@dmarc.ietf.org> Cc: Ketan Talaulikar <ketant.i...@gmail.com> Alexander Vainshtein <Alexander.Vainshtein=40rbbn....@dmarc.ietf.org> draft-dong-spring-srv6-inter-layer-programm...@ietf.org spring@ietf.org Oscar González de Dios <oscar.gonzalezded...@telefonica.com> Subject: Re: [spring] Re: My question at the mike about draft-dong-spring-srv6-inter-layer-programming Hi Jie I have a draft in CCAMP on POI IP + Optical convergence where we are focused on operator use cases for coherent pluggable optics that is being developed by lead author Oscar Dios (Teas chair). Does this describe what you are trying to do with SRv6 inter layer programming does seem like POI IP + Optical convergence. [Jie] As described in this draft, POI is one use case of SRv6 inter-layer programming. This work uses the CS-SR Circuit Style SR for provisioning being progressed by Christian Schmutzer which can be over SR-MPLS or SRv6. https://datatracker.ietf.org/doc/draft-schmutzer-spring-cs-sr-policy/ [Jie] To my understanding CS-SR is a another story, which is about using SR based packet network to emulate circuit-style connections. Gyan> CS-SR is used for provisioning both TDM CES Circuit Emulated services as well as MetroE ethernet 100G/400G/800G per wavelength with ROADM for shared SPAN or w/o ROADM for P2P SPAN. The goal of CS-SR is to provide guaranteed bandwidth with path protection per wavelength for POI both pluggable and non pluggable gray optics with external transponder. The POI integration is done holistically with a hierarchical controller that talks to both IP controller (PCE) IP layer and Optical controller optical layer so that SR can provide the protection failover scheme and optical layer can provide the restoration. I believe there maybe some overlap in vendor implementations of CS-SR with hierarchical controllers and the goals of SRv6 Inter Layer programming. However if the goal of inter layer programming in POI context to provision the optical layer with the IP controller using new SRv6 programming End.XU and End.BXC endpoint behaviors then their is no overlap as this would be an alternative solution to provisioning the optical layer. This would provide simplicity and as well now would not necessarily need a hierarchical controller to talk both IP and Optical layers to provision them both separately. With this solution the IP controller with the new SRv6 endpoint behaviors can now provision both the IP and Optical layers. Or the IP controller via the new endpoint behaviors could talk directly to the optical controller for provisioning. If that maybe the case could you provide more details as to how the optical layer would be provisioned. There are two new very powerful use cases which are exposed with POI when IP and Optical layers are being converged and that is that now with POI we can p2p DWDM links between router nodes that are now acting as DWDM switch as well with Routed Optical Networking termed "RON" with IP and Optical convergence. These use cases do not exist with legacy Optical OTN with gray optics and external transponders which is one of the major benefits of POI IP+Optical convergence https://datatracker.ietf.org/doc/html/draft-poidt-ccamp-actn-poi-pluggable-usecases-gaps-01 With this work we have tremendous scale as now each p2p link with coherent pluggable optics and now having access to all the layers with IP+Optical with a Hierarchial controller superset controller talking to the IP and Optical layers for provisioning as well as can have very long spans with tweaking of the alien wavelengths and amplitude modulation schemes. With POI a p2p link with each router being a DWDM switch each wavelength could be 100G/400G/800G x 96 wavelengths so a single SMF fiber can now have up to 100G/400G/800G x 96 scalable bandwidth on demand which is applicable to MSDC DCI interconnects and Converged Core transport networks. [Jie] Thanks for sharing the use cases of IP+optical pluggable, I will take a further look at it. I agree this draft could be applicable to the use cases of pluggable, and it can also be applied to other IP and Optical integration cases without pluggable. Best regards, Jie This exists today and is supported by a few vendors but now we are trying to standardize the implementation use cases with coherent pluggable optics with this CCAMP draft. See section 4.2 Scenario-A High Capacity P2P and 4.3 Scenario-B High Capacity P2P over shared fiber 4. Network Scenarios This section provides a set of packet over optical network scenarios, starting with the most common ones.¶ 4.1. Scenario A - High capacity point to point connection over dedicated direct fiber As depicted in Figure 4, this scenario considers a point-to-point optical service over a short distance (e.g., up to 100 km) using dedicated fiber.¶ Note that there is no amplification and no protection in this scenario.¶ Packet Packet Device A Device B +----+ IP Link (between Router Ports) +----+ | |.............................................................| | | | | | | | Optical Service (Plug-to-Plug) | | | | ..................................................... | | | |------| |------| | | | | | | | | |Plug A|===================================================|Plug B| | | | | | | | | |------| |------| | | | | | +----+ +----+ Figure 4: Network topology with dedicated direct fiber 4.2. Scenario B - High capacity point to point over shared fiber This scenario extends Figure 4 by making more efficient use of the deployed fiber infrastructure.¶ As shown in Figure 5, this scenario considers a point-to-point optical service over a short distance (e.g., up to 100 km) using a physical optical network with DWDM filters and amplifiers. Several point-to-point connections can be multiplexed from the same packet devices.¶ Note that there is no protection in this scenario.¶ Packet Packet Device A Device B +----+ IP Link (between Router Ports) +----+ | |.............................................................| | | | | | | | Optical Service (Plug-to-Plug) | | | | ..................................................... | | | |------| |------| | | | | |-------| |-------| |-------| | | | | |Plug A|======| Filter|======| AMP |======| Filter|======|Plug B| | | | | ||==| | | | | |==|| | | | | |------| || |-------| |-------| |-------| || |------| | | | || || | | +----+ || || +----+ || || |------| || || |------| | |==|| ||==| | |Plug C| |Plug D| | | | | |------| |-----
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
