Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Xuesong, Thanks for your support and review comments. We are working on a new revision which will take your comments into consideration. As for your suggestion to add reference to the more scalable solution, according to the comments from Acee, we would not mention the specific solution in this draft, but we have referred to the NRP scalability document for more information on the scalability discussion. Hope that would be OK to you. Best regards, Chongfeng From: Gengxuesong (Geng Xuesong) Date: 2024-01-11 18:37 To: Acee Lindem; Lsr Subject: RE: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06 Hi WG, I support the publication of this document. I think this is a reasonable method of network slicing implementation which could reuse the existing mechanism. Some editing comments for authors' reference. Best Xuesong -- 1. Introduction ... This document describes a simplified mechanism to build SR based NRPs in those scenarios. The resource-aware segments can be used with this approach to provide resource guaranteed SR based NRPs, while the normal SR segments may also be used to provide SR based NRPs with shared network resources in the forwarding plane. The proposed approach is to use IS-IS Multi-Topology [RFC5120] with segment routing [RFC8667] to define the independent network topology of each NRP. The network resources and other TE attributes of an NRP can be advertised using IS-IS MT with the Traffic Engineering (TE) extensions defined in [RFC5305] and [RFC8570]. [Xuesong] I recommend to swap the position of these two sentences. It will be easier for readers' understanding: show what is the proposal firstly and then describe this could be used with resource-aware segments to provide resource guaranteed SR based NRPs 2. Advertisement of Topology Attribute for SR based NRP [Xuesong] It will be helpful if there is a summary about what Topology Attribute for SR based NRP is requested before introducing what could be reused in different existing RFCs. 3. Advertisement of Resource Attribute for SR based NRP In order to perform constraint based path computation for each NRP on the network controller or on the ingress nodes, the network resource attributes and other attributes associated with each NRP need to be advertised. [Xuesong] It could be considered to add some explanation for whether this is just for this proposal or also could be used to other resource guaranteed SR based NRPs 5. Scalability Considerations The mechanism described in this document is considered useful for network scenarios in which the required number of NRP is small, as no control protocol extension is required. For network scenarios where the number of required NRP is large, more scalable solution would be needed, which may require further protocol extensions and enhancements. [Xuesong] This is helpful to add some reference for example of more scalable solutions. > -Original Message- > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem > Sent: Tuesday, January 9, 2024 6:50 AM > To: Lsr > Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS > Multi-Topology > (MT) for Segment Routing based Network Resource Partition (NRP)" - > draft-ietf-lsr-isis-sr-vtn-mt-06 > > This begins a two week LSR Working Group last call for the “Applicability of > IS-IS > Multi-Topology (MT) for Segment Routing based Network Resource Partition > (NRP)”. Please express your support or objection prior to Tuesday, January > 23rd, > 2024. > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
HI Reshad,
I've uploaded version -21, which includes the changes we discussed.
Thanks,
Yingzhen
On Mon, Jan 22, 2024 at 11:52 AM Reshad Rahman wrote:
> Thanks Yingzhen. Yes I am good with that.
>
> Regards,
> Reshad.
>
> On Monday, January 22, 2024, 02:39:17 PM EST, Yingzhen Qu <
> yingzhen.i...@gmail.com> wrote:
>
>
> Hi Reshad,
>
> Thanks for the review.
>
> The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with
> more content, so I thought it might be easier to read with a container. But
> you're right, it's not following the YANG traditions, how about the
> following?
>
> container sid-binding-tlvs {
> list sid-binding-tlv {
> key "prefix";
> uses sid-binding-tlv;
> description
> "Sid/label binding TLV, type 149.";
> }
> description
> "List of sid/label binding TLVs.";
> }
> container mt-sid-binding-tlvs {
> list mt-sid-binding-tlv {
> key "prefix mt-id";
> uses sid-binding-tlv;
> leaf mt-id {
> type uint16;
> description
> "A 12-bit field containing the non-zero ID
> of the topology.";
> }
> description
> "Multi-Topology SID/Label binding TLV, type 150.";
> reference
> "RFC 8667 - IS-IS Extensions for Segment Routing,
>Section 2.5";
> }
> description
> "List of multi-topology sid/label binding TLVs.";
> }
>
> Thanks,
> Yingzhen
>
> On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman wrote:
>
> Hi,
>
> Typically we have a container (plural) including a list (singular). In -20
> it was done the other way round. Since this is read-only, IIRC we don't
> need the container including a list as we do for read-write. Is the
> container there for convenience?
>
> Regards,
> Reshad.
>
>
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/isis:isis/isis:database
> /isis:levels/isis:lsp:
> +--ro sid-binding-tlvs* []
> | +--ro sid-binding-tlv
> | +--ro prefix?inet:ip-prefix
> | +--ro range? uint16
> | +--ro sid-binding-flags
> | | +--ro flags* identityref
> | +--ro prefix-sid-sub-tlvs* []
> | | +--ro prefix-sid-sub-tlvs
> | | +--ro prefix-sid-sub-tlv* [sid]
> | |+--ro prefix-sid-flags
> | || +--ro flags* identityref
> | |+--ro algorithm? identityref
> | |+--ro sid uint32
> | +--ro sid-sub-tlvs* []
> | | +--ro sid-sub-tlv
> | | +--ro length? uint8
> | | +--ro sid? uint32
> | +--ro unknown-tlvs
> |+--ro unknown-tlv* []
> | +--ro type? uint16
> | +--ro length? uint16
> | +--ro value?yang:hex-string
> +--ro mt-sid-binding-tlvs* []
>+--ro mt-sid-binding-tlvs
> +--ro prefix?inet:ip-prefix
> +--ro range? uint16
> +--ro sid-binding-flags
> | +--ro flags* identityref
> +--ro prefix-sid-sub-tlvs* []
> | +--ro prefix-sid-sub-tlvs
> | +--ro prefix-sid-sub-tlv* [sid]
> |+--ro prefix-sid-flags
> || +--ro flags* identityref
> |+--ro algorithm? identityref
> |+--ro sid uint32
> +--ro sid-sub-tlvs* []
> | +--ro sid-sub-tlv
> | +--ro length? uint8
> | +--ro sid? uint32
> +--ro unknown-tlvs
> | +--ro unknown-tlv* []
> | +--ro type? uint16
> | +--ro length? uint16
> | +--ro value?yang:hex-string
> +--ro mt-id? uint16
>
> On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman <
> res...@yahoo.com> wrote:
>
>
> [Yingzhen]: Thanks for catching this. I've updated the description.
> I looked at the changes in -20. That grouping is now gone and the
> (mt-)sid-binding-tlvs lists have no key, is that the intent?
> Also container mt-sid-binding-tlvs should be renamed to mt-
> sid-binding-tlv.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-isis-sr-yang-21.txt
Internet-Draft draft-ietf-isis-sr-yang-21.txt is now available. It is a work item of the Link State Routing (LSR) WG of the IETF. Title: A YANG Data Model for IS-IS Segment Routing for the MPLS Data Plane Authors: Stephane Litkowski Yingzhen Qu Pushpasis Sarkar Ing-Wher Chen Jeff Tantsura Name:draft-ietf-isis-sr-yang-21.txt Pages: 33 Dates: 2024-01-22 Abstract: This document defines a YANG data module that can be used to configure and manage IS-IS Segment Routing for MPLS data plane. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-isis-sr-yang-21.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-isis-sr-yang-21 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
Hi all, The adoption call is closed, and the document is not adopted. The author has requested an extension of the adoption call for one week, however since we fail to see new technical points being discussed, the chairs decided to close the call as planned. During the second adoption call, the discussion has been focusing on simplifying inter-as link discovery and topology management although there are existing solutions. Additionally the added use cases were discussed, but are also covered by existing solutions. No rough consensus has been reached about the use cases, nor the solution. Please note: many of the same points were discussed in the first adoption call. In the future, if the authors are to request another adoption call, the condition will be to have a discussion on the list first and achieve rough consensus of the use case and solution. Thanks, Acee, Chris and Yingzhen (LSR Co-chairs) On Thu, Jan 18, 2024 at 5:52 PM Aijun Wang wrote: > Hi, Les: > > > > Let’s top post my responses to your specific questions: > > > > *1) **LAN partitioning can occur. So R1 and R2 may be able to talk > to each and R3 and R4 may be able to talk to each – but the two partitions > have no connectivity. Yet all nodes will advertise the LAN subnet – which > in your world means that you think you have full connectivity when you do > not. * > > [WAJ] If the partition is occurred by design, then R1-R4 should not > declare the same subnet; if the partition is occurred by the switch faulty, > it needs other OAM tools to detect. This is also true for the P2P based > existing solutions(RFC9346/RFC5392). > > > > *2) **Your draft says: “It will be help for the router R0, to know > the attributes of the stub links and select the optimal Anycast server to > serve the customer's application.”.* > > *Given that you don’t actually know which of the anycast servers each of > the border routers can reach (you just “assume” it is all of them) the > ability of R0 to make a correct decision is compromised.* > > [WAJ] Here, “the optimal Anycast server” refer to the “the optimal > path(exits) to Anycast server”. The reason that we use Anycast is that all > these servers can provide the same services. The difference is that the > path attributes(internal links and stub link) to them. > > > > Wish the above explanations can address your concerns. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] *代表 > *Les Ginsberg (ginsberg) > *发送时间:* 2024年1月19日 0:51 > *收件人:* Aijun Wang > *抄送:* 'Christian Hopps' ; 'Huzhibo' ; > 'Acee Lindem' ; 'Yingzhen Qu' < > yingzhen.i...@gmail.com>; lsr@ietf.org > *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > > > Aijun – > > > > Frankly, I have a limited tolerance for these exchanges because your > responses to specific points are evasive. > > You are like a boxer whose main goal is to avoid any punch thrown by your > opponent from landing directly. This is a pretty useful skill in a boxing > ring, but pretty tiresome when trying to have a frank exchange of views on > the technical points of a draft. > > I am unlikely to respond further after this – but please find some > responses inline. See [LES2:]. > > > > *From:* Aijun Wang > *Sent:* Thursday, January 18, 2024 1:29 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* 'Christian Hopps' ; 'Huzhibo' ; > 'Acee Lindem' ; 'Yingzhen Qu' < > yingzhen.i...@gmail.com>; lsr@ietf.org > *Subject:* 答复: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Hi, Les: > > > > *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org > ] *代表 *Les Ginsberg (ginsberg) > *发送时间:* 2024年1月18日 0:16 > *收件人:* Aijun Wang > *抄送:* Christian Hopps ; Huzhibo ; > Acee Lindem ; Yingzhen Qu ; > lsr@ietf.org > *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > > > Aijun - > > > > *From:* Aijun Wang > *Sent:* Tuesday, January 16, 2024 10:56 PM > *To:* Les Ginsberg (ginsberg) > *Cc:* Christian Hopps ; Huzhibo ; > Acee Lindem ; Yingzhen Qu ; > lsr@ietf.org > *Subject:* Re: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Hi, Les: > > > > Let’s keep the discussions simple. > > > > Please answer the following two questions that you haven’t responsed > directly in previous mail: > > 1)How the existing point-to-point based solution(RFC9346/RFC5392) > solve the broadcast(LAN, A.1 Figure2) inter-AS topology recovery > scenario---There are multiple neighbors on one interfaces, which are > located in different AS. How to encode the information within one inter-AS > reachability TLV? > > > > *[LES:] In the absence of the existence of an advertisement of the LAN > itself (the “pseudonode” in IS-IS), a LAN is represented as a set of P2P > links between each of the nodes connected to the
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Thanks Yingzhen. Yes I am good with that.
Regards,Reshad.
On Monday, January 22, 2024, 02:39:17 PM EST, Yingzhen Qu
wrote:
Hi Reshad,
Thanks for the review.
The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with more
content, so I thought it might be easier to read with a container. But you're
right, it's not following the YANG traditions, how about the following?
container sid-binding-tlvs { list sid-binding-tlv { key
"prefix"; uses sid-binding-tlv; description "Sid/label
binding TLV, type 149."; } description "List of sid/label
binding TLVs."; } container mt-sid-binding-tlvs { list
mt-sid-binding-tlv { key "prefix mt-id"; uses sid-binding-tlv;
leaf mt-id { type uint16; description "A
12-bit field containing the non-zero ID of the topology."; }
description "Multi-Topology SID/Label binding TLV, type 150.";
reference "RFC 8667 - IS-IS Extensions for Segment Routing,
Section 2.5"; } description "List of multi-topology
sid/label binding TLVs."; }
Thanks,Yingzhen
On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman wrote:
Hi,
Typically we have a container (plural) including a list (singular). In -20 it
was done the other way round. Since this is read-only, IIRC we don't need the
container including a list as we do for read-write. Is the container there for
convenience?
Regards,Reshad.
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:database
/isis:levels/isis:lsp:
+--ro sid-binding-tlvs* []
| +--ro sid-binding-tlv
| +--ro prefix?inet:ip-prefix
| +--ro range? uint16
| +--ro sid-binding-flags
| | +--ro flags* identityref
| +--ro prefix-sid-sub-tlvs* []
| | +--ro prefix-sid-sub-tlvs
| | +--ro prefix-sid-sub-tlv* [sid]
| |+--ro prefix-sid-flags
| || +--ro flags* identityref
| |+--ro algorithm? identityref
| |+--ro sid uint32
| +--ro sid-sub-tlvs* []
| | +--ro sid-sub-tlv
| | +--ro length? uint8
| | +--ro sid? uint32
| +--ro unknown-tlvs
|+--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value?yang:hex-string
+--ro mt-sid-binding-tlvs* []
+--ro mt-sid-binding-tlvs
+--ro prefix?inet:ip-prefix
+--ro range? uint16
+--ro sid-binding-flags
| +--ro flags* identityref
+--ro prefix-sid-sub-tlvs* []
| +--ro prefix-sid-sub-tlvs
| +--ro prefix-sid-sub-tlv* [sid]
|+--ro prefix-sid-flags
|| +--ro flags* identityref
|+--ro algorithm? identityref
|+--ro sid uint32
+--ro sid-sub-tlvs* []
| +--ro sid-sub-tlv
| +--ro length? uint8
| +--ro sid? uint32
+--ro unknown-tlvs
| +--ro unknown-tlv* []
| +--ro type? uint16
| +--ro length? uint16
| +--ro value?yang:hex-string
+--ro mt-id? uint16On Saturday, January 20, 2024,
06:53:52 PM EST, Reshad Rahman wrote:
[Yingzhen]: Thanks for catching this. I've updated the description. I
looked at the changes in -20. That grouping is now gone and the
(mt-)sid-binding-tlvs lists have no key, is that the intent?Also container
mt-sid-binding-tlvs should be renamed to mt-sid-binding-tlv.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Hi Reshad,
Thanks for the review.
The "sid-binding-tlv" and "mt-sid-binding-tlv" are relatively big with more
content, so I thought it might be easier to read with a container. But
you're right, it's not following the YANG traditions, how about the
following?
container sid-binding-tlvs {
list sid-binding-tlv {
key "prefix";
uses sid-binding-tlv;
description
"Sid/label binding TLV, type 149.";
}
description
"List of sid/label binding TLVs.";
}
container mt-sid-binding-tlvs {
list mt-sid-binding-tlv {
key "prefix mt-id";
uses sid-binding-tlv;
leaf mt-id {
type uint16;
description
"A 12-bit field containing the non-zero ID
of the topology.";
}
description
"Multi-Topology SID/Label binding TLV, type 150.";
reference
"RFC 8667 - IS-IS Extensions for Segment Routing,
Section 2.5";
}
description
"List of multi-topology sid/label binding TLVs.";
}
Thanks,
Yingzhen
On Mon, Jan 22, 2024 at 6:07 AM Reshad Rahman wrote:
> Hi,
>
> Typically we have a container (plural) including a list (singular). In -20
> it was done the other way round. Since this is read-only, IIRC we don't
> need the container including a list as we do for read-write. Is the
> container there for convenience?
>
> Regards,
> Reshad.
>
>
> augment /rt:routing/rt:control-plane-protocols
> /rt:control-plane-protocol/isis:isis/isis:database
> /isis:levels/isis:lsp:
> +--ro sid-binding-tlvs* []
> | +--ro sid-binding-tlv
> | +--ro prefix?inet:ip-prefix
> | +--ro range? uint16
> | +--ro sid-binding-flags
> | | +--ro flags* identityref
> | +--ro prefix-sid-sub-tlvs* []
> | | +--ro prefix-sid-sub-tlvs
> | | +--ro prefix-sid-sub-tlv* [sid]
> | |+--ro prefix-sid-flags
> | || +--ro flags* identityref
> | |+--ro algorithm? identityref
> | |+--ro sid uint32
> | +--ro sid-sub-tlvs* []
> | | +--ro sid-sub-tlv
> | | +--ro length? uint8
> | | +--ro sid? uint32
> | +--ro unknown-tlvs
> |+--ro unknown-tlv* []
> | +--ro type? uint16
> | +--ro length? uint16
> | +--ro value?yang:hex-string
> +--ro mt-sid-binding-tlvs* []
>+--ro mt-sid-binding-tlvs
> +--ro prefix?inet:ip-prefix
> +--ro range? uint16
> +--ro sid-binding-flags
> | +--ro flags* identityref
> +--ro prefix-sid-sub-tlvs* []
> | +--ro prefix-sid-sub-tlvs
> | +--ro prefix-sid-sub-tlv* [sid]
> |+--ro prefix-sid-flags
> || +--ro flags* identityref
> |+--ro algorithm? identityref
> |+--ro sid uint32
> +--ro sid-sub-tlvs* []
> | +--ro sid-sub-tlv
> | +--ro length? uint8
> | +--ro sid? uint32
> +--ro unknown-tlvs
> | +--ro unknown-tlv* []
> | +--ro type? uint16
> | +--ro length? uint16
> | +--ro value?yang:hex-string
> +--ro mt-id? uint16
>
> On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman <
> res...@yahoo.com> wrote:
>
>
> [Yingzhen]: Thanks for catching this. I've updated the description.
> I looked at the changes in -20. That grouping is now gone and the
> (mt-)sid-binding-tlvs lists have no key, is that the intent?
> Also container mt-sid-binding-tlvs should be renamed to mt-
> sid-binding-tlv.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Yangdoctors last call review of draft-ietf-isis-sr-yang-19
Hi, Typically we have a container (plural) including a list (singular). In -20 it was done the other way round. Since this is read-only, IIRC we don't need the container including a list as we do for read-write. Is the container there for convenience? Regards,Reshad. augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/isis:isis/isis:database /isis:levels/isis:lsp: +--ro sid-binding-tlvs* [] | +--ro sid-binding-tlv | +--ro prefix?inet:ip-prefix | +--ro range? uint16 | +--ro sid-binding-flags | | +--ro flags* identityref | +--ro prefix-sid-sub-tlvs* [] | | +--ro prefix-sid-sub-tlvs | | +--ro prefix-sid-sub-tlv* [sid] | |+--ro prefix-sid-flags | || +--ro flags* identityref | |+--ro algorithm? identityref | |+--ro sid uint32 | +--ro sid-sub-tlvs* [] | | +--ro sid-sub-tlv | | +--ro length? uint8 | | +--ro sid? uint32 | +--ro unknown-tlvs |+--ro unknown-tlv* [] | +--ro type? uint16 | +--ro length? uint16 | +--ro value?yang:hex-string +--ro mt-sid-binding-tlvs* [] +--ro mt-sid-binding-tlvs +--ro prefix?inet:ip-prefix +--ro range? uint16 +--ro sid-binding-flags | +--ro flags* identityref +--ro prefix-sid-sub-tlvs* [] | +--ro prefix-sid-sub-tlvs | +--ro prefix-sid-sub-tlv* [sid] |+--ro prefix-sid-flags || +--ro flags* identityref |+--ro algorithm? identityref |+--ro sid uint32 +--ro sid-sub-tlvs* [] | +--ro sid-sub-tlv | +--ro length? uint8 | +--ro sid? uint32 +--ro unknown-tlvs | +--ro unknown-tlv* [] | +--ro type? uint16 | +--ro length? uint16 | +--ro value?yang:hex-string +--ro mt-id? uint16On Saturday, January 20, 2024, 06:53:52 PM EST, Reshad Rahman wrote: [Yingzhen]: Thanks for catching this. I've updated the description. I looked at the changes in -20. That grouping is now gone and the (mt-)sid-binding-tlvs lists have no key, is that the intent?Also container mt-sid-binding-tlvs should be renamed to mt-sid-binding-tlv. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Working Group Last Call for "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)" - draft-ietf-lsr-isis-sr-vtn-mt-06
Hi Acee, I have read the latest version of the document. It's just an informational document and describes a way for using IS-IS MT implement SR based NRP, it gives an informative reference to the operators and implementors who have interests. I think it's a useful document and ready for publication. Best regards, Mach > -Original Message- > From: Lsr On Behalf Of Acee Lindem > Sent: Tuesday, January 9, 2024 6:50 AM > To: Lsr > Subject: [Lsr] Working Group Last Call for "Applicability of IS-IS > Multi-Topology > (MT) for Segment Routing based Network Resource Partition (NRP)" - > draft-ietf-lsr-isis-sr-vtn-mt-06 > > This begins a two week LSR Working Group last call for the “Applicability of > IS-IS > Multi-Topology (MT) for Segment Routing based Network Resource Partition > (NRP)”. Please express your support or objection prior to Tuesday, January > 23rd, > 2024. > > Thanks, > Acee > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
