Hi Les, Agree, if node C and D have a way to get the maximum bandwidth and utilized bandwidth information of themselves, then the two links share a physical link is of no concern to remote nodes.
Best regards Li 发件人: Les Ginsberg (ginsberg) <[email protected]> 发送时间: 2026年3月18日 11:57 收件人: zhangli (CE) <[email protected]>; Acee Lindem <[email protected]> 抄送: Tony Li <[email protected]>; lsr <[email protected]>; [email protected] 主题: [Lsr] Re: New Version Notification for draft-zl-lsr-igp-sub-interface-relationship-00.txt Li - https://www.rfc-editor.org/rfc/rfc8570.html#section-4.7 defines the Unidirectional Utilized Bandwidth Sub-TLV. For a complete list of currently defined sub-TLVs see: https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-advertising-neighbor-information All of these sub-TLVs can be advertised (potentially with different values) in each of the per sub-interface neighbor advertisements. You assume that Node C MUST advertise bandwidth values associated with the physical interface for both of the sub-interface neighbor advertisements. If that were true, then you would be correct in stating that an additional advertisement for each sub-interface would be needed. But, as I have stated: >Assuming nodes C and D have a way to manage bandwidth allocation per >sub-interface (which is necessary regardless of how bandwidth is advertised) >then they can advertise the appropriate values in the existing sub-TLVs for >each >of the two neighbor advertisements between C and D. > The fact that the two links share a physical link is of no concern to remote >nodes. Les >-----Original Message----- >From: zhangli (CE) <[email protected]<mailto:[email protected]>> >Sent: Tuesday, March 17, 2026 8:21 PM >To: Acee Lindem <[email protected]<mailto:[email protected]>>; Les >Ginsberg (ginsberg) ><[email protected]<mailto:[email protected]>> >Cc: Tony Li <[email protected]<mailto:[email protected]>>; lsr ><[email protected]<mailto:[email protected]>>; draft-zl-lsr-igp-sub-interface- >[email protected]<mailto:[email protected]> >Subject: RE: [Lsr] New Version Notification for draft-zl-lsr-igp-sub-interface- >relationship-00.txt > >Hi Les and Acee, > >This is a good point, but it is not enough to only have the physical bandwidth >information, the utilized bandwidth information is also necessary for load >balancing. > >Also we can allocate independent bandwidth information to different sub- >interfaces through technologies such as FlexE or others. But we can not get the >utilized bandwidth information of each sub-interface, that is why we need a >new encoding. > >Best regards >Li > >-----邮件原件----- >发件人: Acee Lindem <[email protected]<mailto:[email protected]>> >发送时间: 2026年3月18日 10:25 >收件人: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> >抄送: zhangli (CE) <[email protected]<mailto:[email protected]>>; Tony >Li <[email protected]<mailto:[email protected]>>; lsr ><[email protected]<mailto:[email protected]>>; >[email protected]<mailto:[email protected]> >主题: Re: [Lsr] New Version Notification for draft-zl-lsr-igp-sub-interface- >relationship-00.txt > >That's a good point. If you take the trouble to define sub-interfaces, why >would >you want to manage the bandwidth at the physical link level? >What is the motivation for such sub-interface configuration? > >Thanks, >Acee > >> On Mar 17, 2026, at 6:18 PM, Les Ginsberg (ginsberg) >> <[email protected]<mailto:[email protected]>> >wrote: >> >> And I am claiming there is no need for either of the new sub-TLVs. >> Assuming nodes C and D have a way to manage bandwidth allocation per >sub-interface (which is necessary regardless of how bandwidth is advertised) >then they can advertise the appropriate values in the existing sub-TLVs for >each >of the two neighbor advertisements between C and D. >> The fact that the two links share a physical link is of no concern to remote >nodes. >> This is why I stated that bullet point #2 on Slide 3 of the WG presentation: >> When two directly connected IS-IS neighbors are established through >> sub-interfaces, the Link Bandwidth and Utilized Bandwidth of the >> sub-interfaces are just inherited form their parent physical interface. >> Is incorrect. If you want the bandwidth of the sub-interfaces to be treated >independently, then clearly you have to be able to manage the bandwidth >usage independently on the local nodes (C and D in this case). >> Once you do that, there is no need for any new encodings. C and D simply >advertise the per sub-interface bandwidth in existing sub-TLVs. >> BTW, if one were to use the proposed extensions, they would not be >backwards compatible. Legacy nodes in the network would never look for the >presence of the new sub-TLVs and so they would use the parent bandwidth >values. >> I don’t think we should pursue this. >> Les >> >-----Original Message----- >> >From: Acee Lindem <[email protected]<mailto:[email protected]>> >> >Sent: Tuesday, March 17, 2026 2:53 PM >> >To: zhangli (CE) <[email protected]<mailto:[email protected]>> >> >Cc: Tony Li <[email protected]<mailto:[email protected]>>; lsr >> ><[email protected]<mailto:[email protected]>>; >> >draft-zl-lsr-igp-sub-interface- >> >[email protected]<mailto:[email protected]> >> >Subject: [Lsr] Re: New Version Notification for >> >draft-zl-lsr-igp-sub-interface- relationship-00.txt >> > >Hi Li, >> > >My question during your presentation of this draft is why you need >> > >the sub- >> >TLVs in section 2.1 relating to a neighbor. >> >For the use case in section 4, it would seem you would only need the >> >sub-TLV identifying the physical interface defined in section 2.2. I >> >see no use case for the 2.1 sub-TLVs. >> > >Thanks, >> >Acee >> > >> On Mar 3, 2026, at 8:36 AM, zhangli (CE) >> > >> <[email protected]<mailto:[email protected]>> >wrote: >> >> >> Hi Tony and Acee, >> >> >> Thanks a lot for your valuable comments and insights. >> >> >> Tony's understanding is right, it is based on the case where >> >> >> someone has >> >multiple VLANs over one link between two routers. As Acee mentioned, >> >there are many cases that a router establishes several links with >> >another router by several sub-interfaces in the practical network >deployment. >> >> >> However, a sub-interface does not have its own independent >> >> >> bandwidth and >> >utilization information, its bandwidth and utilization information is >> >just copied from their parent physical interface. >> >> >> When a remote device want to do load balancing based on the >> >> >> available >> >bandwidth information, it can not know that several links are sharing >> >the same physical bandwidth. This may lead to an unbalanced load, >> >even result in packet loss when the traffic on a physical interface exceeds >> >it >max bandwidth. >> >> >> Therefore, this document propose extensions to IGP to advertise >> >> >> the >> >relationship between a physical interface and its sub-interfaces. >> >This information is valuable for load balancing in the head end. >> >> >> >> Best regards >> >> Li >> >>> -----邮件原件----- >> >>> 发件人: Acee Lindem <[email protected]<mailto:[email protected]>> >> >>> 发送时间: 2026年3月2日 20:28 >> >>> 收件人: Tony Li <[email protected]<mailto:[email protected]>> >> >>> 抄送: zhangli (CE) <[email protected]<mailto:[email protected]>>; >> >>> lsr <[email protected]<mailto:[email protected]>>; >> >>> [email protected]<mailto:[email protected]> >> >>> 主题: Re: [Lsr] New Version Notification for >> >>> draft-zl-lsr-igp-sub-interface-relationship-00.txt >> >>> >>> Hi Zhang, Tony, >> >>> >>>> On Mar 2, 2026, at 2:10 AM, Tony Li >> >>> >>>> <[email protected]<mailto:[email protected]>> wrote: >> >>>> >>>> >>>> Hi Zhang Li, >> >>>> >>>> Perhaps I’m not understanding the problem that you’re trying to >solve. >> >>>> It seems to me that what you’re suggesting is that we create a >> >>>> special encoding to handle the case where someone has multiple >> >>>> VLANs over one link between two routers. Is that correct? Why >> >>>> would anyone want to do that? I >> >>> >>> This is a common way to include an interface in multiple areas >> >>> >>> in OSPFv2. I >> >>> expect it is used in OSPFv3 as well since people don't know how to >> >>> configure different Instance IDs. >> >>> >>> >>>> dislike adding hair to the protocol over a situation that should >not exist. >> >>> >>> I haven't read the draft but I don't see why it makes any >> >>> >>> difference to the >> >IGPs >> >>> and agree. >> >>> >>> Thanks, >> >>> Acee >> >>> >>> >>>> >>>> Regards, >> >>>> Tony >> >>>> >>>> >>>>> On Mar 1, 2026, at 6:56 PM, zhangli (CE) - >> >>>> >>>> >>>>> zhangli344=40huawei.com at >> >>> dmarc.ietf.org >> >>> <[email protected]<mailto:[email protected]>> wrote: >> >>>>> >>>>> Dear all, >> >>>>> >>>>> A new document >> >>>>> >>>>> draft-zl-lsr-igp-sub-interface-relationship-00 has been >> >>> submitted. This draft introduces extensions to IGP, allowing a >> >>> network device >> >to >> >>> advertise the relationship between a physical interface and its sub- >interfaces. >> >>> These extensions enable the links based on sub-interfaces to >> >>> participate in >> >the >> >>> alternative paths for load balancing. >> >>>>> >>>>> Links for the draft is as below. >> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-zl-lsr-igp-sub-inte >> >>>>> >>>>> rface-relat >> >>>>> ionship/ >> >>>>> >>>>> Looking forward to your review and comments. >> >>>>> >>>>> Best regards >> >>>>> Li >> >>>>> -----邮件原件----- >> >>>>> 发件人: [email protected]<mailto:[email protected]> >> >>>>> <[email protected]<mailto:[email protected]>> >> >>>>> 发送时间: 2026年2月28日 17:12 >> >>>>> 收件人: lichenxi (A) <[email protected]<mailto:[email protected]>>; >> >>>>> Dongjie (Jimmy) >> >>>>> <[email protected]<mailto:[email protected]>>; zhangli (CE) >> >>>>> <[email protected]<mailto:[email protected]>> >> >>>>> 主题: New Version Notification for >> >>>>> draft-zl-lsr-igp-sub-interface-relationship-00.txt >> >>>>> >>>>> A new version of Internet-Draft >> >>>>> draft-zl-lsr-igp-sub-interface-relationship-00.txt has been >> >>>>> successfully >> >>> submitted by Li Zhang and posted to the IETF repository. >> >>>>> >>>>> Name: draft-zl-lsr-igp-sub-interface-relationship >> >>>>> Revision: 00 >> >>>>> Title: IGP Extensions for Sub-interface Relationship Information >> >>>>> Date: 2026-02-28 >> >>>>> Group: Individual Submission >> >>>>> Pages: 8 >> >>>>> URL: >> >>> https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-rel >> >>> ationship- >> >00.txt >> >>>>> Status: >> >>> https://datatracker.ietf.org/doc/draft-zl-lsr-igp-sub-interface-re >> >>> lationship/ >> >>>>> HTML: >> >>> https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-rel >> >>> ationship- >> >00.ht >> >>> ml >> >>>>> HTMLized: >> >>>>> https://datatracker.ietf.org/doc/html/draft-zl-lsr-igp-sub-inter >> >>>>> face- >> >>>>> relationship >> >>>>> >>>>> >>>>> Abstract: >> >>>>> >>>>> This document extends ISIS and OSPF, allowing a network >> >>>>> >>>>> device to >> >>>>> advertise the relationship between a physical interface and its >> >>>>> sub- interfaces. This extension enables the links based on >> >>>>> sub-interfaces to participate in the alternative paths for load >> >>>>> balancing in SRv6 BE bandwidth polling. >> >>>>> >>>>> >>>>> >>>>> The IETF Secretariat >> >>>>> >>>>> >>>>> _______________________________________________ >> >>>>> Lsr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe >> >>>>> send an email to >> >>>>> [email protected]<mailto:[email protected]> >> >>>> >>>> _______________________________________________ >> >>>> Lsr mailing list -- [email protected]<mailto:[email protected]> >> >>>> To unsubscribe send an email to >> >>>> [email protected]<mailto:[email protected]> >> >> > >_______________________________________________ >> >Lsr mailing list -- [email protected]<mailto:[email protected]> >> >To unsubscribe send an email to >> >[email protected]<mailto:[email protected]> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
