[Lsr] Re: New Version Notification for draft-zl-lsr-igp-sub-interface-relationship-00.txt

[je_dr...@yahoo.com]

Les, Your logic impeccable. John Sent from my iPhone On Mar 17, 2026, at 6:18 PM, Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> 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 <acee.i...@gmail.com> >Sent: Tuesday, March 17, 2026 2:53 PM >To: zhangli (CE) <zhangli...@huawei.com> >Cc: Tony Li <tony...@tony.li>; lsr <lsr@ietf.org>; draft-zl-lsr-igp-sub-interface- >relationship.auth...@ietf.org >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) <zhangli...@huawei.com> 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 <acee.i...@gmail.com> >>> 发送时间: 2026年3月2日 20:28 >>> 收件人: Tony Li <tony...@tony.li> >>> 抄送: zhangli (CE) <zhangli...@huawei.com>; lsr <lsr@ietf.org>; >>> draft-zl-lsr-igp-sub-interface-relationship.auth...@ietf.org >>> 主题: 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 <tony...@tony.li> 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 <mailforwa...@cloudmails.net> 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 >>>>> -----邮件原件----- >>>>> 发件人: internet-dra...@ietf.org <internet-dra...@ietf.org> >>>>> 发送时间: 2026年2月28日 17:12 >>>>> 收件人: lichenxi (A) <lichen...@huawei.com>; Dongjie (Jimmy) >>>>> <jie.d...@huawei.com>; zhangli (CE) <zhangli...@huawei.com> >>>>> 主题: 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 -- lsr@ietf.org >>>>> To unsubscribe send an email to lsr-le...@ietf.org >>>>  >>>> _______________________________________________ >>>> Lsr mailing list -- lsr@ietf.org >>>> To unsubscribe send an email to lsr-le...@ietf.org >>  >  >_______________________________________________ >Lsr mailing list -- lsr@ietf.org >To unsubscribe send an email to lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org

_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org