Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Gyan, Thanks a lot for your review and comments. I agree with your summary of the basic concept in enhanced VPN framework draft. It is about the integration of overlay and a subset of underlay network topology and resource to provide the required service connectivity and performance assurance. Source routing with current SR-MPLS or SRv6 is one important feature to achieve service path customization, and the color based matching of services to SR policy is useful in general. While performance assurance requires additional capability such as resource management and reservation on paths or virtual networks used for different services. I think existing SR mechanism needs to be enhanced to support resource awareness and provide resource guaranteed SR paths or virtual networks. These are described in draft-dong-spring-sr-enhanced-vpn. You can also review it if you like. Thanks. Chongfeng From: Gyan Mishra Date: 2020-03-30 05:13 To: Tony Przygienda CC: Aijun Wang; Dongjie (Jimmy); Les Ginsberg (ginsberg); Les Ginsberg (ginsberg); Peter Psenak; lsr@ietf.org; peng.sha...@zte.com.cn; xie...@chinatelecom.cn Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi Chongfeng & Jie I read through this draft which is referenced in the MT draft which is a good to read first to provide context as to what you are trying to accomplish with VPN+ idea. https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 In reading both documents the basic concept at a high level is that you are trying to provide a means of pinning overlay vpn service to underlay transport providing a form of isolation abstraction. From a Spring Source routing standpoint source routing provided by segment routing flavors SR-MPLS and SRv6 provides the same vpn coloring and source routed traffic engineering via SR-TE for SR-MPLS and SRv6 native L3 vpn coloring with SRH traffic steering. So that coupling for IP SLA requirement of underlay pinning to overlay vpn via traffic steering coloring via candidate ERO paths to me seems to be satisfied by Segment Routing flavors. Am I missing something? Kind regards Gyan https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 On Sun, Mar 29, 2020 at 12:30 PM Tony Przygienda wrote: As usual +1 Les Simply think what is the _L3 construct_ ISIS runs over which is easily identified as the same thing that adjacency runs over. If adjacency runs over each constituent of L2 bundel we don't have L2, we have L3 with confused naming. If adjacency runs over the L2 bundle the bundle is an L3 construct and hence MTID applies again, to keep things orthogonal (mostly on the encoding side but also underlying architecture) I would derive 225 the same way we run 222. Otherwise we end up in funky places like "what happens if this bundle has more than one MTID and if it runs on no MT and a MTID" as well and what does it mean if it's missing and what if someone doesn't understand it and so on and so on. That stuff has been pretty well reviewed and thought out when it was done and all the tlv/subtlv discussions had then ... --- tony On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) wrote: Peter/Aijun - We are in agreement. I never said that an L2 Bundle member could/should be associated with a specific MTID. It is the L3 adjacency that has the MTID association. If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor". Les > -Original Message- > From: Lsr On Behalf Of Aijun Wang > Sent: Sunday, March 29, 2020 3:46 AM > To: Peter Psenak > Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) ; > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) > ; lsr@ietf.org; Tony Przygienda > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > basedVirtual Transport Network > > I have the same consideration as Peter. > > Aijun Wang > China Telecom > > > On Mar 29, 2020, at 17:10, Peter Psenak > wrote: > > > > Hi Les, > > > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: > >> Tony – > >> There are a few misunderstandings in your post. > >> Let me try to correct them. > >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of > TLVs 22,23,141,222,223. > >> Conceptually, it could have been defined as a sub-TLV, but because of the > limited length of a TLV in IS-IS (255 octets) and the likelihood that > advertising > L2Bundle member attributes would consume a significant amount of space, > we decided to use a new top-level TLV which references the associated L3 > adjacency advertised in TLV 22. This means TLV22 advertisements are not > impacted by the presence of TLV 25. In particular, the use of TLV 25 does
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Robert, Good question. In short you may need some mechanism in the forwarding plane to isolate the traffic in the default topology from the traffic in other topologies. Some of the candidate technologies are described in draft-ietf-teas-enhanced-vpn. Best regards, Jie From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Monday, March 30, 2020 6:21 PM To: Dongjie (Jimmy) Cc: peng.sha...@zte.com.cn; Aijun Wang ; xie...@chinatelecom.cn; lsr@ietf.org Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi, Out of pure curiosity here - how are you going to stop any other traffic (SR or non SR) to take as much as it likes of any link being part of the default topology ? Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi, Out of pure curiosity here - how are you going to stop any other traffic (SR or non SR) to take as much as it likes of any link being part of the default topology ? Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Tony, Thanks for your comments. My current understanding is TLV 25 could reference the associated L3 link advertised in either TLV 22 or 222. With your proposal of keeping things orthogonal, does it mean that TLV 25 would only be used to advertise the member link attributes of the associated L3 link in TLV 22, and a new TLV 225 needs to be defined for advertising member link attributes of the associated L3 link in corresponding TLV 222? Then if an L3 link is advertised with multiple TLV 222 for different topologies, does its member link attributes also need be advertised multiple times in multiple TLV 225? Best regards, Jie From: Tony Przygienda [mailto:tonysi...@gmail.com] Sent: Monday, March 30, 2020 12:29 AM To: Les Ginsberg (ginsberg) Cc: Aijun Wang ; Peter Psenak ; peng.sha...@zte.com.cn; Dongjie (Jimmy) ; xie...@chinatelecom.cn; Les Ginsberg (ginsberg) ; lsr@ietf.org Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network As usual +1 Les Simply think what is the _L3 construct_ ISIS runs over which is easily identified as the same thing that adjacency runs over. If adjacency runs over each constituent of L2 bundel we don't have L2, we have L3 with confused naming. If adjacency runs over the L2 bundle the bundle is an L3 construct and hence MTID applies again, to keep things orthogonal (mostly on the encoding side but also underlying architecture) I would derive 225 the same way we run 222. Otherwise we end up in funky places like "what happens if this bundle has more than one MTID and if it runs on no MT and a MTID" as well and what does it mean if it's missing and what if someone doesn't understand it and so on and so on. That stuff has been pretty well reviewed and thought out when it was done and all the tlv/subtlv discussions had then ... --- tony On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Peter/Aijun - We are in agreement. I never said that an L2 Bundle member could/should be associated with a specific MTID. It is the L3 adjacency that has the MTID association. If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor". Les > -Original Message- > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of > Aijun Wang > Sent: Sunday, March 29, 2020 3:46 AM > To: Peter Psenak > mailto:40cisco@dmarc.ietf.org>> > Cc: peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>; Dongjie (Jimmy) > mailto:jie.d...@huawei.com>>; > xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; Les Ginsberg (ginsberg) > mailto:40cisco@dmarc.ietf.org>>; > lsr@ietf.org<mailto:lsr@ietf.org>; Tony Przygienda > mailto:tonysi...@gmail.com>> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > basedVirtual Transport Network > > I have the same consideration as Peter. > > Aijun Wang > China Telecom > > > On Mar 29, 2020, at 17:10, Peter Psenak > mailto:40cisco@dmarc.ietf.org>> wrote: > > > > Hi Les, > > > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: > >> Tony – > >> There are a few misunderstandings in your post. > >> Let me try to correct them. > >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of > TLVs 22,23,141,222,223. > >> Conceptually, it could have been defined as a sub-TLV, but because of the > limited length of a TLV in IS-IS (255 octets) and the likelihood that > advertising > L2Bundle member attributes would consume a significant amount of space, > we decided to use a new top-level TLV which references the associated L3 > adjacency advertised in TLV 22. This means TLV22 advertisements are not > impacted by the presence of TLV 25. In particular, the use of TLV 25 does not > lead to multiple TLV 22 advertisements for the same adjacency, which we > thought was a desirable outcome. > >> The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr- > ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit > length for TLVs it does not face the same encoding issues. > >> I fully agree with you that an L2 bundle is a Layer 3 construct – and as > >> such > can be associated with any Layer 3 MTID in theory. However, when writing > RFC 8668 we did not consider that there was a use case for topology specific > link attributes. The current encoding does not support MTID. > > > > RFC 8668 defines a TLV to advertise attributes of the individual L2 link > members. While the TLV itself can be considered as L3 construct (and have > MT associated with it), the individual L2 Bundle Member Links inside th
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Les, On 29/03/2020 17:57, Les Ginsberg (ginsberg) wrote: Peter/Aijun - We are in agreement. I never said that an L2 Bundle member could/should be associated with a specific MTID. ok, but that is what the authors of the draft-xie-lsr-isis-sr-vtn-mt are proposing. That's the reason why I was opposing that idea. It is the L3 adjacency that has the MTID association. If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor". sure, although it looks redundant to me, given that the same L3 link is already advertised in other TLV which can have MTID in it. thanks, Peter Les -Original Message- From: Lsr On Behalf Of Aijun Wang Sent: Sunday, March 29, 2020 3:46 AM To: Peter Psenak Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) ; xie...@chinatelecom.cn; Les Ginsberg (ginsberg) ; lsr@ietf.org; Tony Przygienda Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network I have the same consideration as Peter. Aijun Wang China Telecom On Mar 29, 2020, at 17:10, Peter Psenak wrote: Hi Les, On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: Tony – There are a few misunderstandings in your post. Let me try to correct them. RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223. Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome. The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr- ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not face the same encoding issues. I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID. RFC 8668 defines a TLV to advertise attributes of the individual L2 link members. While the TLV itself can be considered as L3 construct (and have MT associated with it), the individual L2 Bundle Member Links inside this TLV are not L3 constructs IMHO and should never have a MTID associated with them. The ask here is to advertise different MTID for each individual L2 bundle member link. MTID is used to construct a topology. I do not see how a L2 bundle link member would ever become part of the L3 topology. my 2c, Peter At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222. HTH Les *From:* Lsr *On Behalf Of * Tony Przygienda *Sent:* Saturday, March 28, 2020 10:25 AM *To:* peng.shaofu@ ___ 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] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Chongfeng & Jie Have you looked at the preferred path routing draft by Uma Chunduri. This is also Isis extensions for IP based SR source routing. Maybe something that can be leveraged for VPN+ https://tools.ietf.org/html/draft-chunduri-isis-preferred-path-routing-00 Also this TEAS draft related to using the RSVP extensions for IP based source routing for SR. This may help in having to develop new extensions for VPN+ https://tools.ietf.org/html/draft-saad-teas-rsvpte-ip-tunnels-00 Kind regards Gyan On Sun, Mar 29, 2020 at 5:13 PM Gyan Mishra wrote: > > Hi Chongfeng & Jie > > I read through this draft which is referenced in the MT draft which is a > good to read first to provide context as to what you are trying to > accomplish with VPN+ idea. > > https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 > > > In reading both documents the basic concept at a high level is that you > are trying to provide a means of pinning overlay vpn service to underlay > transport providing a form of isolation abstraction. > > From a Spring Source routing standpoint source routing provided by segment > routing flavors SR-MPLS and SRv6 provides the same vpn coloring and source > routed traffic engineering via SR-TE for SR-MPLS and SRv6 native L3 vpn > coloring with SRH traffic steering. > > So that coupling for IP SLA requirement of underlay pinning to overlay vpn > via traffic steering coloring via candidate ERO paths to me seems to be > satisfied by Segment Routing flavors. > > Am I missing something? > > Kind regards > > Gyan > > https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 > > > On Sun, Mar 29, 2020 at 12:30 PM Tony Przygienda > wrote: > >> As usual +1 Les >> >> Simply think what is the _L3 construct_ ISIS runs over which is easily >> identified as the same thing that adjacency runs over. If adjacency runs >> over each constituent of L2 bundel we don't have L2, we have L3 with >> confused naming. If adjacency runs over the L2 bundle the bundle is an L3 >> construct and hence MTID applies >> >> again, to keep things orthogonal (mostly on the encoding side but also >> underlying architecture) I would derive 225 the same way we run 222. >> Otherwise we end up in funky places like "what happens if this bundle has >> more than one MTID and if it runs on no MT and a MTID" as well and what >> does it mean if it's missing and what if someone doesn't understand it and >> so on and so on. That stuff has been pretty well reviewed and thought out >> when it was done and all the tlv/subtlv discussions had then ... >> >> >> --- tony >> >> On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) < >> ginsb...@cisco.com> wrote: >> >>> Peter/Aijun - >>> >>> We are in agreement. >>> I never said that an L2 Bundle member could/should be associated with a >>> specific MTID. >>> >>> It is the L3 adjacency that has the MTID association. >>> If we were going to support MTID in TLV 25 the correct place to put it >>> would be as part of the " Parent L3 Neighbor Descriptor". >>> >>> Les >>> >>> >>> > -Original Message- >>> > From: Lsr On Behalf Of Aijun Wang >>> > Sent: Sunday, March 29, 2020 3:46 AM >>> > To: Peter Psenak >>> > Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) >> >; >>> > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) >>> > ; lsr@ietf.org; Tony Przygienda >>> > >>> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing >>> > basedVirtual Transport Network >>> > >>> > I have the same consideration as Peter. >>> > >>> > Aijun Wang >>> > China Telecom >>> > >>> > > On Mar 29, 2020, at 17:10, Peter Psenak >>> > wrote: >>> > > >>> > > Hi Les, >>> > > >>> > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: >>> > >> Tony – >>> > >> There are a few misunderstandings in your post. >>> > >> Let me try to correct them. >>> > >> RFC 8668 defines a new top-level TLV (25). This is NOT a >>> sub-TLV(sic) of >>> > TLVs 22,23,141,222,223. >>> > >> Conceptually, it could have been defined as a sub-TLV, but because >>> of the >>> > limited length of a TLV in IS-IS (255 octets) and the likelihood that >>> advertising >>> > L2Bundle member attribut
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Chongfeng & Jie I read through this draft which is referenced in the MT draft which is a good to read first to provide context as to what you are trying to accomplish with VPN+ idea. https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 In reading both documents the basic concept at a high level is that you are trying to provide a means of pinning overlay vpn service to underlay transport providing a form of isolation abstraction. >From a Spring Source routing standpoint source routing provided by segment routing flavors SR-MPLS and SRv6 provides the same vpn coloring and source routed traffic engineering via SR-TE for SR-MPLS and SRv6 native L3 vpn coloring with SRH traffic steering. So that coupling for IP SLA requirement of underlay pinning to overlay vpn via traffic steering coloring via candidate ERO paths to me seems to be satisfied by Segment Routing flavors. Am I missing something? Kind regards Gyan https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn-05 On Sun, Mar 29, 2020 at 12:30 PM Tony Przygienda wrote: > As usual +1 Les > > Simply think what is the _L3 construct_ ISIS runs over which is easily > identified as the same thing that adjacency runs over. If adjacency runs > over each constituent of L2 bundel we don't have L2, we have L3 with > confused naming. If adjacency runs over the L2 bundle the bundle is an L3 > construct and hence MTID applies > > again, to keep things orthogonal (mostly on the encoding side but also > underlying architecture) I would derive 225 the same way we run 222. > Otherwise we end up in funky places like "what happens if this bundle has > more than one MTID and if it runs on no MT and a MTID" as well and what > does it mean if it's missing and what if someone doesn't understand it and > so on and so on. That stuff has been pretty well reviewed and thought out > when it was done and all the tlv/subtlv discussions had then ... > > > --- tony > > On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > >> Peter/Aijun - >> >> We are in agreement. >> I never said that an L2 Bundle member could/should be associated with a >> specific MTID. >> >> It is the L3 adjacency that has the MTID association. >> If we were going to support MTID in TLV 25 the correct place to put it >> would be as part of the " Parent L3 Neighbor Descriptor". >> >>Les >> >> >> > -Original Message- >> > From: Lsr On Behalf Of Aijun Wang >> > Sent: Sunday, March 29, 2020 3:46 AM >> > To: Peter Psenak >> > Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) > >; >> > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) >> > ; lsr@ietf.org; Tony Przygienda >> > >> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing >> > basedVirtual Transport Network >> > >> > I have the same consideration as Peter. >> > >> > Aijun Wang >> > China Telecom >> > >> > > On Mar 29, 2020, at 17:10, Peter Psenak >> > wrote: >> > > >> > > Hi Les, >> > > >> > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: >> > >> Tony – >> > >> There are a few misunderstandings in your post. >> > >> Let me try to correct them. >> > >> RFC 8668 defines a new top-level TLV (25). This is NOT a >> sub-TLV(sic) of >> > TLVs 22,23,141,222,223. >> > >> Conceptually, it could have been defined as a sub-TLV, but because >> of the >> > limited length of a TLV in IS-IS (255 octets) and the likelihood that >> advertising >> > L2Bundle member attributes would consume a significant amount of space, >> > we decided to use a new top-level TLV which references the associated L3 >> > adjacency advertised in TLV 22. This means TLV22 advertisements are not >> > impacted by the presence of TLV 25. In particular, the use of TLV 25 >> does not >> > lead to multiple TLV 22 advertisements for the same adjacency, which we >> > thought was a desirable outcome. >> > >> The equivalent OSPF draft ( >> https://tools.ietf.org/html/draft-ketant-lsr- >> > ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 >> bit >> > length for TLVs it does not face the same encoding issues. >> > >> I fully agree with you that an L2 bundle is a Layer 3 construct – >> and as such >> > can be associated with any Layer 3 MTID in theory. However, when writing >> > RFC 8668 we did not consider that there was a use case fo
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
As usual +1 Les Simply think what is the _L3 construct_ ISIS runs over which is easily identified as the same thing that adjacency runs over. If adjacency runs over each constituent of L2 bundel we don't have L2, we have L3 with confused naming. If adjacency runs over the L2 bundle the bundle is an L3 construct and hence MTID applies again, to keep things orthogonal (mostly on the encoding side but also underlying architecture) I would derive 225 the same way we run 222. Otherwise we end up in funky places like "what happens if this bundle has more than one MTID and if it runs on no MT and a MTID" as well and what does it mean if it's missing and what if someone doesn't understand it and so on and so on. That stuff has been pretty well reviewed and thought out when it was done and all the tlv/subtlv discussions had then ... --- tony On Sun, Mar 29, 2020 at 8:57 AM Les Ginsberg (ginsberg) wrote: > Peter/Aijun - > > We are in agreement. > I never said that an L2 Bundle member could/should be associated with a > specific MTID. > > It is the L3 adjacency that has the MTID association. > If we were going to support MTID in TLV 25 the correct place to put it > would be as part of the " Parent L3 Neighbor Descriptor". > >Les > > > > -Original Message- > > From: Lsr On Behalf Of Aijun Wang > > Sent: Sunday, March 29, 2020 3:46 AM > > To: Peter Psenak > > Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) ; > > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) > > ; lsr@ietf.org; Tony Przygienda > > > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > > basedVirtual Transport Network > > > > I have the same consideration as Peter. > > > > Aijun Wang > > China Telecom > > > > > On Mar 29, 2020, at 17:10, Peter Psenak > > wrote: > > > > > > Hi Les, > > > > > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: > > >> Tony – > > >> There are a few misunderstandings in your post. > > >> Let me try to correct them. > > >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) > of > > TLVs 22,23,141,222,223. > > >> Conceptually, it could have been defined as a sub-TLV, but because of > the > > limited length of a TLV in IS-IS (255 octets) and the likelihood that > advertising > > L2Bundle member attributes would consume a significant amount of space, > > we decided to use a new top-level TLV which references the associated L3 > > adjacency advertised in TLV 22. This means TLV22 advertisements are not > > impacted by the presence of TLV 25. In particular, the use of TLV 25 > does not > > lead to multiple TLV 22 advertisements for the same adjacency, which we > > thought was a desirable outcome. > > >> The equivalent OSPF draft ( > https://tools.ietf.org/html/draft-ketant-lsr- > > ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 > bit > > length for TLVs it does not face the same encoding issues. > > >> I fully agree with you that an L2 bundle is a Layer 3 construct – and > as such > > can be associated with any Layer 3 MTID in theory. However, when writing > > RFC 8668 we did not consider that there was a use case for topology > specific > > link attributes. The current encoding does not support MTID. > > > > > > RFC 8668 defines a TLV to advertise attributes of the individual L2 > link > > members. While the TLV itself can be considered as L3 construct (and have > > MT associated with it), the individual L2 Bundle Member Links inside > this TLV > > are not L3 constructs IMHO and should never have a MTID associated with > > them. The ask here is to advertise different MTID for each individual L2 > > bundle member link. > > > > > > MTID is used to construct a topology. I do not see how a L2 bundle link > > member would ever become part of the L3 topology. > > > > > > my 2c, > > > Peter > > > > > > > > >> At this point, if we needed to extend RFC 8668 to support MTID we > would > > need to allocate an additional TLV code point that included MTID – > similar to > > the distinction between TLV 22 and TLV 222. > > >> HTH > > >>Les > > >> *From:* Lsr *On Behalf Of * Tony Przygienda > > >> *Sent:* Saturday, March 28, 2020 10:25 AM > > >> *To:* peng.shaofu@ > > > > ___ > > 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] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Peter/Aijun - We are in agreement. I never said that an L2 Bundle member could/should be associated with a specific MTID. It is the L3 adjacency that has the MTID association. If we were going to support MTID in TLV 25 the correct place to put it would be as part of the " Parent L3 Neighbor Descriptor". Les > -Original Message- > From: Lsr On Behalf Of Aijun Wang > Sent: Sunday, March 29, 2020 3:46 AM > To: Peter Psenak > Cc: peng.sha...@zte.com.cn; Dongjie (Jimmy) ; > xie...@chinatelecom.cn; Les Ginsberg (ginsberg) > ; lsr@ietf.org; Tony Przygienda > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > basedVirtual Transport Network > > I have the same consideration as Peter. > > Aijun Wang > China Telecom > > > On Mar 29, 2020, at 17:10, Peter Psenak > wrote: > > > > Hi Les, > > > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: > >> Tony – > >> There are a few misunderstandings in your post. > >> Let me try to correct them. > >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of > TLVs 22,23,141,222,223. > >> Conceptually, it could have been defined as a sub-TLV, but because of the > limited length of a TLV in IS-IS (255 octets) and the likelihood that > advertising > L2Bundle member attributes would consume a significant amount of space, > we decided to use a new top-level TLV which references the associated L3 > adjacency advertised in TLV 22. This means TLV22 advertisements are not > impacted by the presence of TLV 25. In particular, the use of TLV 25 does not > lead to multiple TLV 22 advertisements for the same adjacency, which we > thought was a desirable outcome. > >> The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr- > ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit > length for TLVs it does not face the same encoding issues. > >> I fully agree with you that an L2 bundle is a Layer 3 construct – and as > >> such > can be associated with any Layer 3 MTID in theory. However, when writing > RFC 8668 we did not consider that there was a use case for topology specific > link attributes. The current encoding does not support MTID. > > > > RFC 8668 defines a TLV to advertise attributes of the individual L2 link > members. While the TLV itself can be considered as L3 construct (and have > MT associated with it), the individual L2 Bundle Member Links inside this TLV > are not L3 constructs IMHO and should never have a MTID associated with > them. The ask here is to advertise different MTID for each individual L2 > bundle member link. > > > > MTID is used to construct a topology. I do not see how a L2 bundle link > member would ever become part of the L3 topology. > > > > my 2c, > > Peter > > > > > >> At this point, if we needed to extend RFC 8668 to support MTID we would > need to allocate an additional TLV code point that included MTID – similar to > the distinction between TLV 22 and TLV 222. > >> HTH > >>Les > >> *From:* Lsr *On Behalf Of * Tony Przygienda > >> *Sent:* Saturday, March 28, 2020 10:25 AM > >> *To:* peng.shaofu@ > > ___ > 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] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
I have the same consideration as Peter. Aijun Wang China Telecom > On Mar 29, 2020, at 17:10, Peter Psenak > wrote: > > Hi Les, > >> On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: >> Tony – >> There are a few misunderstandings in your post. >> Let me try to correct them. >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of >> TLVs 22,23,141,222,223. >> Conceptually, it could have been defined as a sub-TLV, but because of the >> limited length of a TLV in IS-IS (255 octets) and the likelihood that >> advertising L2Bundle member attributes would consume a significant amount of >> space, we decided to use a new top-level TLV which references the associated >> L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not >> impacted by the presence of TLV 25. In particular, the use of TLV 25 does >> not lead to multiple TLV 22 advertisements for the same adjacency, which we >> thought was a desirable outcome. >> The equivalent OSPF draft >> (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes the >> sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not >> face the same encoding issues. >> I fully agree with you that an L2 bundle is a Layer 3 construct – and as >> such can be associated with any Layer 3 MTID in theory. However, when >> writing RFC 8668 we did not consider that there was a use case for topology >> specific link attributes. The current encoding does not support MTID. > > RFC 8668 defines a TLV to advertise attributes of the individual L2 link > members. While the TLV itself can be considered as L3 construct (and have MT > associated with it), the individual L2 Bundle Member Links inside this TLV > are not L3 constructs IMHO and should never have a MTID associated with them. > The ask here is to advertise different MTID for each individual L2 bundle > member link. > > MTID is used to construct a topology. I do not see how a L2 bundle link > member would ever become part of the L3 topology. > > my 2c, > Peter > > >> At this point, if we needed to extend RFC 8668 to support MTID we would need >> to allocate an additional TLV code point that included MTID – similar to the >> distinction between TLV 22 and TLV 222. >> HTH >>Les >> *From:* Lsr *On Behalf Of * Tony Przygienda >> *Sent:* Saturday, March 28, 2020 10:25 AM >> *To:* peng.shaofu@ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Les, On 29/03/2020 00:00, Les Ginsberg (ginsberg) wrote: Tony – There are a few misunderstandings in your post. Let me try to correct them. RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223. Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome. The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not face the same encoding issues. I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID. RFC 8668 defines a TLV to advertise attributes of the individual L2 link members. While the TLV itself can be considered as L3 construct (and have MT associated with it), the individual L2 Bundle Member Links inside this TLV are not L3 constructs IMHO and should never have a MTID associated with them. The ask here is to advertise different MTID for each individual L2 bundle member link. MTID is used to construct a topology. I do not see how a L2 bundle link member would ever become part of the L3 topology. my 2c, Peter At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222. HTH Les *From:* Lsr *On Behalf Of * Tony Przygienda *Sent:* Saturday, March 28, 2020 10:25 AM *To:* peng.sha...@zte.com.cn *Cc:* xie...@chinatelecom.cn; Dongjie (Jimmy) ; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network I'm surprised by where this discussion is heading, what prevents you from sticking TLV25 into MT TLVs or actually aren't you contradicting existing standards RFC? First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously fwd' L3 frames. MT is nothing else but associating a L3 adjacency with an MT so if you run a normal adjacency over normal L2 bundle so you can an MT adjacency .. And funny enough rft8668 even says The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. Whether you use that for slicing is a different discussion, you are bound by 12 bits worth of MTs as first observation. 2nd, it forces you on a very orthogonal but hence very manageable ;-) architecture where both sides of the interface must be configured for the things to associate. And you have to repate prefixes per MT if you wnat them reachabl3e in multiple MTs if that makes sense (i.e. you don't use MT to disassociate addressing but only to manage link resources). "Color";ing on the other hand does not seem to have much of an architecture AFAIS but is rather like tag'ing keywords in a post, you hope you can make some kind of algorithm deliver some kind of coherent forwarding behavior (just like querying for some combinations/substring/presence/absence of keywords in a query on bunch of "things"). While this is surely more flexible in case you don't need all the flexiblity the manageability of the whole things looks to me daunting. A good analogy is MPLS vs SR here. If you wnat a nailed, guaranteed end-2-end connectivity with clear OAM/resource allocation/behavior on failures/topology changes MPLS is your friend, SR gives you arguably more flexibility but the question where the traffic goes on changes, resource allocation, stats, behavior on failures/changes is something that is far more daunting to get a handle on. my 2c -- tony On Fri, Mar 27, 2020 at 9:08 PM <mailto:peng.sha...@zte.com.cn>> wrote: Hi Peter, and other folks This topic is very interesting. it happend that we also consider this topic in draft-peng-lsr-flex-algo-l2bundles-00, and draft-zch-lsr-isis-network-slicing-02. I totally agree Peter that MT can not be used for L2 members. IMO, both Flex-algo and AII can be extended to address this topic, but MT not. Thanks, PSF 原始邮件 *发件人：*PeterPsenak mailto:40cisco@dmarc.ietf.org>
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Tony – By having the new TLV 25 share the same set of sub-TLV codepoints with TLVs 22 etc., we did not have to define new sub-TLVs in order to advertise the link attributes (bandwidth, affinity, etc.) in TLV 25. The only relationship between TLV 25 and TLV 22 lies in the “Parent L3 Neighbor Descriptor” – which includes the system-id/pseudo-node ID of the neighbor and (in the case of parallel links to the same neighbor) link endpoint identifiers. Les From: Tony Przygienda Sent: Saturday, March 28, 2020 5:56 PM To: Les Ginsberg (ginsberg) Cc: peng.sha...@zte.com.cn; xie...@chinatelecom.cn; Dongjie (Jimmy) ; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Still, taht reads utterly inconsistent to me ? This document adds the following new TLV to the IS-IS "TLV Codepoints Registry". Value: 25 Name: L2 Bundle Member Attributes The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda mailto:tonysi...@gmail.com>> wrote: On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> wrote: Tony – There are a few misunderstandings in your post. Let me try to correct them. RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223. ack, forgot how l2-bundle was working in detail and on quick re-reading the language misled me since it talks about so many tlv & sub-tlv spaces. Ack, 25 is TLV. thanks for correction. Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome. ah, ok, now that makes sense, I didn't know the precise history here. To be orthogonal to previous MT-ID designs we should have a 225 (that's not taken AFAIR) with MTID just like we have a 222 for 22 ... not a large amount of work. I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID. At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222. ack, as I say 225 seems empty if need arises ;-) thanks for keeping me honest as usual ;-) --- tony ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Still, taht reads utterly inconsistent to me ? This document adds the following new TLV to the IS-IS "TLV Codepoints Registry". Value: 25 Name: L2 Bundle Member Attributes *The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25.* On Sat, Mar 28, 2020 at 5:52 PM Tony Przygienda wrote: > > > On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) < > ginsb...@cisco.com> wrote: > >> Tony – >> >> >> >> There are a few misunderstandings in your post. >> >> Let me try to correct them. >> >> >> >> RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of >> TLVs 22,23,141,222,223. >> > > ack, forgot how l2-bundle was working in detail and on quick re-reading > the language misled me since it talks about so many tlv & sub-tlv spaces. > Ack, 25 is TLV. thanks for correction. > > >> >> Conceptually, it could have been defined as a sub-TLV, but because of the >> limited length of a TLV in IS-IS (255 octets) and the likelihood that >> advertising L2Bundle member attributes would consume a significant amount >> of space, we decided to use a new top-level TLV which references the >> associated L3 adjacency advertised in TLV 22. This means TLV22 >> advertisements are not impacted by the presence of TLV 25. In particular, >> the use of TLV 25 does not lead to multiple TLV 22 advertisements for the >> same adjacency, which we thought was a desirable outcome. >> > > ah, ok, now that makes sense, I didn't know the precise history here. To > be orthogonal to previous MT-ID designs we should have a 225 (that's not > taken AFAIR) with MTID just like we have a 222 for 22 ... not a large > amount of work. > > >> >> >> I fully agree with you that an L2 bundle is a Layer 3 construct – and as >> such can be associated with any Layer 3 MTID in theory. However, when >> writing RFC 8668 we did not consider that there was a use case for topology >> specific link attributes. The current encoding does not support MTID. >> >> At this point, if we needed to extend RFC 8668 to support MTID we would >> need to allocate an additional TLV code point that included MTID – similar >> to the distinction between TLV 22 and TLV 222. >> > > ack, as I say 225 seems empty if need arises ;-) > > thanks for keeping me honest as usual ;-) > > --- tony > >> ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
On Sat, Mar 28, 2020 at 4:01 PM Les Ginsberg (ginsberg) wrote: > Tony – > > > > There are a few misunderstandings in your post. > > Let me try to correct them. > > > > RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of > TLVs 22,23,141,222,223. > ack, forgot how l2-bundle was working in detail and on quick re-reading the language misled me since it talks about so many tlv & sub-tlv spaces. Ack, 25 is TLV. thanks for correction. > > Conceptually, it could have been defined as a sub-TLV, but because of the > limited length of a TLV in IS-IS (255 octets) and the likelihood that > advertising L2Bundle member attributes would consume a significant amount > of space, we decided to use a new top-level TLV which references the > associated L3 adjacency advertised in TLV 22. This means TLV22 > advertisements are not impacted by the presence of TLV 25. In particular, > the use of TLV 25 does not lead to multiple TLV 22 advertisements for the > same adjacency, which we thought was a desirable outcome. > ah, ok, now that makes sense, I didn't know the precise history here. To be orthogonal to previous MT-ID designs we should have a 225 (that's not taken AFAIR) with MTID just like we have a 222 for 22 ... not a large amount of work. > > > I fully agree with you that an L2 bundle is a Layer 3 construct – and as > such can be associated with any Layer 3 MTID in theory. However, when > writing RFC 8668 we did not consider that there was a use case for topology > specific link attributes. The current encoding does not support MTID. > > At this point, if we needed to extend RFC 8668 to support MTID we would > need to allocate an additional TLV code point that included MTID – similar > to the distinction between TLV 22 and TLV 222. > ack, as I say 225 seems empty if need arises ;-) thanks for keeping me honest as usual ;-) --- tony > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Tony – There are a few misunderstandings in your post. Let me try to correct them. RFC 8668 defines a new top-level TLV (25). This is NOT a sub-TLV(sic) of TLVs 22,23,141,222,223. Conceptually, it could have been defined as a sub-TLV, but because of the limited length of a TLV in IS-IS (255 octets) and the likelihood that advertising L2Bundle member attributes would consume a significant amount of space, we decided to use a new top-level TLV which references the associated L3 adjacency advertised in TLV 22. This means TLV22 advertisements are not impacted by the presence of TLV 25. In particular, the use of TLV 25 does not lead to multiple TLV 22 advertisements for the same adjacency, which we thought was a desirable outcome. The equivalent OSPF draft (https://tools.ietf.org/html/draft-ketant-lsr-ospf-l2bundles-01 ) takes the sub-TLV approach, but since OSPF has a 16 bit length for TLVs it does not face the same encoding issues. I fully agree with you that an L2 bundle is a Layer 3 construct – and as such can be associated with any Layer 3 MTID in theory. However, when writing RFC 8668 we did not consider that there was a use case for topology specific link attributes. The current encoding does not support MTID. At this point, if we needed to extend RFC 8668 to support MTID we would need to allocate an additional TLV code point that included MTID – similar to the distinction between TLV 22 and TLV 222. HTH Les From: Lsr On Behalf Of Tony Przygienda Sent: Saturday, March 28, 2020 10:25 AM To: peng.sha...@zte.com.cn Cc: xie...@chinatelecom.cn; Dongjie (Jimmy) ; ppsenak=40cisco@dmarc.ietf.org; lsr@ietf.org Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network I'm surprised by where this discussion is heading, what prevents you from sticking TLV25 into MT TLVs or actually aren't you contradicting existing standards RFC? First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously fwd' L3 frames. MT is nothing else but associating a L3 adjacency with an MT so if you run a normal adjacency over normal L2 bundle so you can an MT adjacency .. And funny enough rft8668 even says The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. Whether you use that for slicing is a different discussion, you are bound by 12 bits worth of MTs as first observation. 2nd, it forces you on a very orthogonal but hence very manageable ;-) architecture where both sides of the interface must be configured for the things to associate. And you have to repate prefixes per MT if you wnat them reachabl3e in multiple MTs if that makes sense (i.e. you don't use MT to disassociate addressing but only to manage link resources). "Color";ing on the other hand does not seem to have much of an architecture AFAIS but is rather like tag'ing keywords in a post, you hope you can make some kind of algorithm deliver some kind of coherent forwarding behavior (just like querying for some combinations/substring/presence/absence of keywords in a query on bunch of "things"). While this is surely more flexible in case you don't need all the flexiblity the manageability of the whole things looks to me daunting. A good analogy is MPLS vs SR here. If you wnat a nailed, guaranteed end-2-end connectivity with clear OAM/resource allocation/behavior on failures/topology changes MPLS is your friend, SR gives you arguably more flexibility but the question where the traffic goes on changes, resource allocation, stats, behavior on failures/changes is something that is far more daunting to get a handle on. my 2c -- tony On Fri, Mar 27, 2020 at 9:08 PM mailto:peng.sha...@zte.com.cn>> wrote: Hi Peter, and other folks This topic is very interesting. it happend that we also consider this topic in draft-peng-lsr-flex-algo-l2bundles-00, and draft-zch-lsr-isis-network-slicing-02. I totally agree Peter that MT can not be used for L2 members. IMO, both Flex-algo and AII can be extended to address this topic, but MT not. Thanks, PSF 原始邮件 发件人：PeterPsenak mailto:40cisco@dmarc.ietf.org>> 收件人：Dongjie (Jimmy) mailto:jie.d...@huawei.com>>;xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn> mailto:xie...@chinatelecom.cn>>;lsr mailto:lsr@ietf.org>>; 日 期 ：2020年03月27日 23:45 主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi Dongjie, On 27/03/2020 16:32, Dongjie (Jimmy) wrote: > Hi Peter, > > My question actually is: where does the TLV 222 column in the IANA registry > come from? As it is not specified in the IANA section of RFC 5120. It would > be helpful if you or anyone else could share some more information about > this. If normative specification of u
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Peng – Thanx for calling attention to your relatively new draft. The new sub-TLV you propose in https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-00#section-5.1 is unnecessary. You seem to have misunderstood RFC 8668 and believe that it does not allow advertising link attributes which are potentially common to multiple bundle members but in a given deployment are actually unique to each bundle member. This is incorrect. Each L2 Bundle Attribute Descriptor defines the set of bundle members to which the following link attributes sub-TLVs apply. That set can be one bundle member – or it can be multiple bundle members. In the case where you want to advertise unique EAG values for each bundle member you can do so by using L2 Bundle Attribute Descriptors which specify a single bundle member. You may wish to study the Appendix in RFC 8668 which provides example encodings. I appreciate that the encoding defined in RFC 8668 is more complex than most TLV encodings. It represents a tradeoff between encoding efficiency and complexity. We tried to reduce the cases where a link attribute common to multiple bundle members had to be advertised multiple times – but this did result in some additional complexity in the structure of the TLV. Given the IS-IS TLV length limitation of 255 octets and the possibility of bundles with a large number of members this was an important consideration. Les From: Lsr On Behalf Of peng.sha...@zte.com.cn Sent: Friday, March 27, 2020 9:08 PM To: ppsenak=40cisco@dmarc.ietf.org Cc: xie...@chinatelecom.cn; jie.d...@huawei.com; lsr@ietf.org Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi Peter, and other folks This topic is very interesting. it happend that we also consider this topic in draft-peng-lsr-flex-algo-l2bundles-00, and draft-zch-lsr-isis-network-slicing-02. I totally agree Peter that MT can not be used for L2 members. IMO, both Flex-algo and AII can be extended to address this topic, but MT not. Thanks, PSF 原始邮件 发件人：PeterPsenak mailto:ppsenak=40cisco@dmarc.ietf.org>> 收件人：Dongjie (Jimmy) mailto:jie.d...@huawei.com>>;xie...@chinatelecom.cn mailto:xie...@chinatelecom.cn>>;lsr mailto:lsr@ietf.org>>; 日 期 ：2020年03月27日 23:45 主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi Dongjie, On 27/03/2020 16:32, Dongjie (Jimmy) wrote: > Hi Peter, > > My question actually is: where does the TLV 222 column in the IANA registry > come from? As it is not specified in the IANA section of RFC 5120. It would > be helpful if you or anyone else could share some more information about > this. If normative specification of using TE attributes in TLV 222 could be > found in an RFC, we would add a reference to it and remove the editor's note > in section 3.1 of this document. I guess it came with RFC 5120. please see more inline: > > And please see some further replies inline about the L2 bundle discussion. > > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Friday, March 27, 2020 4:11 PM > To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; > xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; lsr > mailto:lsr@ietf.org>> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based > Virtual Transport Network > > Hi Dongjie, > > On 27/03/2020 07:56, Dongjie (Jimmy) wrote: >> Hi Peter, >> >> You missed some of my comments in previous mail, could you also reply to >> this? >> >>> Although the IANA registry shows that all the TE attributes could be used >>> in TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware >>> of), could you help to provide the reference to such IANA specification? In >>> addition, it seems not all of the TE attributes are suitable to be carried >>> at per-topology level. Thus the IANA registry may need to be updated. > > my reading of RFC 5120 and the existing IANA registry is that it is legal to > advertise TE attributes in MT TLVs: > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 > > It says "y" for all TE attributes. What else do you need? > >> >> And please see further replies inline with [Jie]: >> >> -Original Message- >> From: Peter Psenak [mailto:ppse...@cisco.com] >> Sent: Thursday, March 26, 2020 7:03 PM >> To: Dongjie (Jimmy) mailto:jie.d...@huawei.com>>; >> xie...@chinatelecom.cn<mailto:xie...@chinatelecom.cn>; lsr >> mailto:lsr@ietf.org>> >> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing >> ba
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
I'm surprised by where this discussion is heading, what prevents you from sticking TLV25 into MT TLVs or actually aren't you contradicting existing standards RFC? First, an L2 link bundle (I assume we talk about 8668 here) is a L3 concept in ISIS since you run an adjacency over it and obviously fwd' L3 frames. MT is nothing else but associating a L3 adjacency with an MT so if you run a normal adjacency over normal L2 bundle so you can an MT adjacency . And funny enough rft8668 even says The name of the IANA registry for Sub-TLVs for TLVs 22, 23, 141, 222, and 223 has been changed to include sub-TLV 25. Whether you use that for slicing is a different discussion, you are bound by 12 bits worth of MTs as first observation. 2nd, it forces you on a very orthogonal but hence very manageable ;-) architecture where both sides of the interface must be configured for the things to associate. And you have to repate prefixes per MT if you wnat them reachabl3e in multiple MTs if that makes sense (i.e. you don't use MT to disassociate addressing but only to manage link resources). "Color";ing on the other hand does not seem to have much of an architecture AFAIS but is rather like tag'ing keywords in a post, you hope you can make some kind of algorithm deliver some kind of coherent forwarding behavior (just like querying for some combinations/substring/presence/absence of keywords in a query on bunch of "things"). While this is surely more flexible in case you don't need all the flexiblity the manageability of the whole things looks to me daunting. A good analogy is MPLS vs SR here. If you wnat a nailed, guaranteed end-2-end connectivity with clear OAM/resource allocation/behavior on failures/topology changes MPLS is your friend, SR gives you arguably more flexibility but the question where the traffic goes on changes, resource allocation, stats, behavior on failures/changes is something that is far more daunting to get a handle on. my 2c -- tony On Fri, Mar 27, 2020 at 9:08 PM wrote: > > Hi Peter, and other folks > > > This topic is very interesting. it happend that we also consider this > topic in draft-peng-lsr-flex-algo-l2bundles-00, and > draft-zch-lsr-isis-network-slicing-02. > > I totally agree Peter that MT can not be used for L2 members. IMO, both > Flex-algo and AII can be extended to address this topic, but MT not. > > > Thanks, > > PSF > > > 原始邮件 > *发件人：*PeterPsenak > *收件人：*Dongjie (Jimmy) ;xie...@chinatelecom.cn < > xie...@chinatelecom.cn>;lsr ; > *日 期 ：*2020年03月27日 23:45 > *主 题 ：**Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > basedVirtual Transport Network* > Hi Dongjie, > > On 27/03/2020 16:32, Dongjie (Jimmy) wrote: > > Hi Peter, > > > > > My question actually is: where does the TLV 222 column in the IANA registry > > come from? As it is not specified in the IANA section of RFC 5120. It would > > be helpful if you or anyone else could share some more information about > > this. If normative specification of using TE attributes in TLV 222 could be > > found in an RFC, we would add a reference to it and remove the editor's > > note in section 3.1 of this document. > > I guess it came with RFC 5120. > > please see more inline: > > > > > > > And please see some further replies inline about the L2 bundle discussion. > > > > -Original Message- > > From: Peter Psenak [mailto:ppse...@cisco.com] > > Sent: Friday, March 27, 2020 4:11 PM > > To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr < > lsr@ietf.org> > > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing > > based Virtual Transport Network > > > > Hi Dongjie, > > > > On 27/03/2020 07:56, Dongjie (Jimmy) wrote: > >> Hi Peter, > >> > > >> You missed some of my comments in previous mail, could you also reply to > >> this? > >> > > >>> Although the IANA registry shows that all the TE attributes could be used > >>> in TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm > >>> aware of), could you help to provide the reference to such IANA > >>> specification? In addition, it seems not all of the TE attributes are > >>> suitable to be carried at per-topology level. Thus the IANA registry may > >>> need to be updated.. > > > > > my reading of RFC 5120 and the existing IANA registry is that it is legal > > to advertise TE attributes in MT TLVs: > > > > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 > > > > It says "y"
Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network
Hi Peter, and other folks This topic is very interesting. it happend that we also consider this topic in draft-peng-lsr-flex-algo-l2bundles-00, and draft-zch-lsr-isis-network-slicing-02. I totally agree Peter that MT can not be used for L2 members. IMO, both Flex-algo and AII can be extended to address this topic, but MT not. Thanks, PSF 原始邮件 发件人：PeterPsenak 收件人：Dongjie (Jimmy) ;xie...@chinatelecom.cn ;lsr ; 日 期 ：2020年03月27日 23:45 主 题 ：Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network Hi Dongjie, On 27/03/2020 16:32, Dongjie (Jimmy) wrote: > Hi Peter, > > My question actually is: where does the TLV 222 column in the IANA registry > come from? As it is not specified in the IANA section of RFC 5120. It would > be helpful if you or anyone else could share some more information about > this. If normative specification of using TE attributes in TLV 222 could be > found in an RFC, we would add a reference to it and remove the editor's note > in section 3.1 of this document. I guess it came with RFC 5120. please see more inline: > > And please see some further replies inline about the L2 bundle discussion. > > -Original Message- > From: Peter Psenak [mailto:ppse...@cisco.com] > Sent: Friday, March 27, 2020 4:11 PM > To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr > > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based > Virtual Transport Network > > Hi Dongjie, > > On 27/03/2020 07:56, Dongjie (Jimmy) wrote: >> Hi Peter, >> >> You missed some of my comments in previous mail, could you also reply to >> this? >> >>> Although the IANA registry shows that all the TE attributes could be used >>> in TLV 222/223, this was not specified in RFC 5120 (or other RFCs I'm aware >>> of), could you help to provide the reference to such IANA specification? In >>> addition, it seems not all of the TE attributes are suitable to be carried >>> at per-topology level. Thus the IANA registry may need to be updated. > > my reading of RFC 5120 and the existing IANA registry is that it is legal to > advertise TE attributes in MT TLVs: > > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223 > > It says "y" for all TE attributes. What else do you need? > >> >> And please see further replies inline with [Jie]: >> >> -Original Message- >> From: Peter Psenak [mailto:ppse...@cisco.com] >> Sent: Thursday, March 26, 2020 7:03 PM >> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; lsr >> >> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing >> based Virtual Transport Network >> >> Hi Dongjie, >> >> On 26/03/2020 11:57, Dongjie (Jimmy) wrote: >>> Hi Peter, >>> >>> Thanks for your comments. >>> >>>> -Original Message- >>>> From: Peter Psenak [mailto:ppse...@cisco.com] >>>> Sent: Thursday, March 26, 2020 5:23 PM >>>> To: Dongjie (Jimmy) ; xie...@chinatelecom.cn; >>>> lsr >>>> Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment >>>> Routing based Virtual Transport Network >>>> >>>> Hi Dongjie, >>>> >>>> On 26/03/2020 07:40, Dongjie (Jimmy) wrote: >>>>> Hi Peter, >>>>> >>>>> As described in the abstract, the purpose of this draft is to >>>>> define a simplified >>>> control plane mechanism to build SR based Virtual Transport Network >>>> (VTN), it is based on the combination of IS-IS Multi-Topology with >>>> other IS-IS extensions, e.g. the extensions for TE, SR and L2 bundle. >>>> In a word, it tries to reuse the existing TLVs as much as possible. >>>> >>>> reusing the TLVs is not something that needs a standardization. >>>> >>>>> >>>>> That said, this document introduces the mechanism of specifying >>>> per-topology TE attributes, which was not covered in the existing >>>> IS-IS MT (RFC 5120). >>>> >>>> I can clearly see that TLVs defined in RFC5120 are listed in the >>>> registry of sub-TLVs available for TLV 222/223 >>>> >>>> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepo >>>> i >>>> nts.xhtm >>>> l#isis-tlv-codepoints-22-23-25-141-222-223 >>>> >>>> So I'm not sure what you are adding. >>> >>> I
