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]<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-interface-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-relationship-<https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-relationship-00.txt> >00.txt<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-<https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-relationship-00.ht> >00.ht<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]<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]
