Re: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Les,

Thanks for your comments. Please see zzh> below for clarifications.


Juniper Business Use Only
-----Original Message-----
From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: Friday, April 5, 2024 6:36 PM
To: [e-mail]; IETF-Announce <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering A BIER Router To A BIER incapable Router) to Proposed Standard

[External Email. Be cautious of content]


This draft is at a minimum underspecified and has some technical errors in the encoding which should be addressed prior to publication.

There is no discussion as to what the "address" should be in the proposed "BIER Helped node" sub-sub-TLVs.
I would presume that what should be used is the "Router-ID" as specified in the various protocols - but there is no mention of this and I think there should be.

Zzh> The draft does say the following:

   The Type is TBD1 (in the case of ISIS), TBD2 (in the case of OSPFv2),
   of TBD3 (in the case of OSPFv3).  The Value field starts with a one-
   octet Priority field, followed by a one-octet Reserved field, and
* then the Address of the Helped Node (X).  The Length is 6 for IPv4
* and 18 for IPv6 respectively.

Zzh> I can add "4 or 16 octets" to the following figure to make it explicit:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type       |   Length      |    Priority   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Address of the Helped Node  (4 or 16 octets)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


As there is provision for IPv4 and/or IPv6, this suggests that a given router could send two such sub-sub-TLVs - one for each address-family. But there is no discussion as to whether this is allowed nor is it discussed what would happen if a given node advertised multiple such sub-sub-TLVs for the same address family.

Zzh> The draft does say the following, which should be clear?

   ...  The helper node (BFRx) MUST advertise
   one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in
   the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in
   the case of OSPF, one for each helped node:

The name as defined in the IANA section is "BIER Helped Node" - but I would think this was meant to be "BIER Helper Node". (I could argue that a more apt name would be "BIER Tether Node".)

Zzh> It is indeed "Helped Node". The Helper node advertises one sub-sub-TLV for each helped node. I tend to think "helped node" is better than "tether node" or "tethered node" for three reasons:
Zzh> a) the document uses "helper/helped" node throughout.
Zzh> b) seems to me that with "tether node" and "tethered node" it is not as clear on which one is the helper
Zzh> c) somehow to me the wording "tether" implies directly connected; though the document started with that scenario, it has been expanded to include remote helpers.


The encoding defined in Section 3.1 needs to be made protocol specific. OSPF typically pads things to a four byte boundary, but IS-IS does not - which means the "Reserved" field should not be present for IS-IS.

Zzh> It is for possible future extension purposes instead of padding. If you say it is important to save bytes in ISIS signaling, I can remove it but otherwise I'd like to keep it. Please let me know.

I am not enamored of this technology - but at this time I will refrain from commenting further as the WG seems to have decided to go forward.
But please address the comments above.

Apologies for the lateness of these comments.

Zzh> Thanks!
Zzh> Jeffrey

   Les


> -----Original Message-----
> From: BIER <[e-mail]> On Behalf Of The IESG
> Sent: Thursday, February 15, 2024 6:22 AM
> To: IETF-Announce <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: [Bier] Last Call: <draft-ietf-bier-tether-04.txt> (Tethering
> A BIER Router To A BIER incapable Router) to Proposed Standard
>
>
> The IESG has received a request from the Bit Indexed Explicit
> Replication WG
> (bier) to consider the following document: - 'Tethering A BIER Router
> To A BIER incapable Router'
>   <draft-ietf-bier-tether-04.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2024-02-29. Exceptionally,
> comments may be sent to [e-mail] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document specifies optional procedures to optimize the handling
>    of Bit Index Explicit Replication (BIER) incapable routers, by
>    attaching (tethering) a BIER router to a BIER incapable router.
>
>
>
>
>
> The file can be obtained via
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> f-bier-tether/__;!!NEt6yMaO-gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S
> 8Qz44ePY-vB12NTqD4fHt9pgsqPZaldvVYKmMJLu2$
>
>
> The following IPR Declarations may be related to this I-D:
>
>
> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3331/__;!
> !NEt6yMaO-gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12NTqD4
> fHt9pgsqPZaldvVYC2HqNh0$
>
>
>
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12N
> TqD4fHt9pgsqPZaldvVYLcO-qjO$