Hi Acee,
Thanks for your kindly comments. If I understand correctly, you mean the “Link
Local/Remote Identifiers sub-TLV”. Actually it is used to indicate the physical
link that the sub-interface belongs to. Within this TLV, the link remote
identifier is not necessary, and can be empty. But the link local identifier is
necessary for identifying the local physical interface.
This information is also used in the use case described in Section 4. Device A
can not know the relationship between physical interface d and sub-interface
d1/d2 as shown below.
"
* Node D
- Physical interface d
o Bandwidth attributes of interface d（physical bandwidth and
bandwidth utilization ratio）
o sub-interface d1
o sub-interface d2
"
Best regards
Li
-----邮件原件-----
发件人: Acee Lindem <[email protected]>
发送时间: 2026年3月18日 5:53
收件人: 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
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-rel
>>>> at
>>>> 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-relati
>> onship-00.txt
>>>> Status:
>> https://datatracker.ietf.org/doc/draft-zl-lsr-igp-sub-interface-relat
>> ionship/
>>>> HTML:
>> https://www.ietf.org/archive/id/draft-zl-lsr-igp-sub-interface-relati
>> onship-00.ht
>> ml
>>>> HTMLized:
>>>> https://datatracker.ietf.org/doc/html/draft-zl-lsr-igp-sub-interfac
>>>> e-
>>>> 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]
