Hi Li, This seems to be a circular argument - you need separate bandwidth advertisement because there are multiple sub-interfaces? My question is why you defined the subinterfaces in the first place and want to manage the bandwidth at the physical interface level? The fact that there are multiple sub-interfaces implies some separation of traffic. What is the use case?
Thanks, Acee > On Mar 17, 2026, at 11:20 PM, zhangli (CE) <[email protected]> wrote: > > 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]
