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]> > 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]> > >Sent: Tuesday, March 17, 2026 2:53 PM > >To: zhangli (CE) <[email protected]> > >Cc: Tony Li <[email protected]>; lsr <[email protected]>; > >draft-zl-lsr-igp-sub-interface- > >[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]> 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]> > >>> 发送时间: 2026年3月2日 20:28 > >>> 收件人: Tony Li <[email protected]> > >>> 抄送: zhangli (CE) <[email protected]>; lsr <[email protected]>; > >>> [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]> 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]> 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-interface-relat > >>>>> ionship/ > >>>>> >>>>> Looking forward to your review and comments. > >>>>> >>>>> Best regards > >>>>> Li > >>>>> -----邮件原件----- > >>>>> 发件人: [email protected] <[email protected]> > >>>>> 发送时间: 2026年2月28日 17:12 > >>>>> 收件人: lichenxi (A) <[email protected]>; Dongjie (Jimmy) > >>>>> <[email protected]>; zhangli (CE) <[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-relationship- > >00.txt > >>>>> Status: > >>> https://datatracker.ietf.org/doc/draft-zl-lsr-igp-sub-interface-relationship/ > >>>>> HTML: > >>> https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-relationship- > >00.ht > >>> ml > >>>>> HTMLized: > >>>>> https://datatracker.ietf.org/doc/html/draft-zl-lsr-igp-sub-interface- > >>>>> 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] > >>>>> To unsubscribe send an email to [email protected] > >>>> >>>> _______________________________________________ > >>>> Lsr mailing list -- [email protected] > >>>> To unsubscribe send an email to [email protected] > >> > >_______________________________________________ > >Lsr mailing list -- [email protected] > >To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
