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]> 发送时间: 2026年3月18日 10:25 收件人: Les Ginsberg (ginsberg) <[email protected]> 抄送: zhangli (CE) <[email protected]>; Tony Li <[email protected]>; lsr <[email protected]>; [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]> > 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-inte > >>>>> >>>>> rface-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-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] 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]
