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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Jeffrey -



Thanx for the prompt response. (Better than me. 😊)

Please see inline.



> -----Original Message-----

> From: BIER <[e-mail]> On Behalf Of Jeffrey (Zhaohui) Zhang

> Sent: Monday, April 8, 2024 7:03 AM

> To: Les Ginsberg (ginsberg) <[e-mail]>; [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

>

> Hi Les,

>

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

>

>

> Juniper Business Use Only

> -----Original Message-----

> From: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>

> Sent: Friday, April 5, 2024 6:36 PM

> To: [e-mail]<mailto:[e-mail]>; IETF-Announce <[e-mail]<mailto:[e-mail]>>

> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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:

>

[LES:] MY confusion is not with the size of the addresses - it is with what addresses for a given node should be used.

I would think you want to use advertised Router IDs - just asking for that to be mentioned.

Otherwise, I do not know how you expect the various helper nodes to advertise the same address(es) for the same helped node.





>         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:

>

[LES:] So, what Helper Nodes are advertising is really a list(sic) of the nodes for which they can act as helper.

Your encoding is not optimized for that use. More on that below.

> 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.

[LES:] Ack - after a more careful reading I agree.



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.



[LES:] First, reserving space for possible expansion means we send more bytes than needed. I am not a fan. And since you don’t indicate what the reserved field might be (flags, op code of some sort, ...) the probability that you can add information w/o backwards compatibility issues may be low.

The more flexible way of adding extensions would be to support sub-TLVs.



Second, if what you are advertising is really a list of helped nodes, one can imagine a more efficient encoding where you can advertise multiple addresses in a single sub-TLV.

To do that what you need is an AF indicator (so that the address length can be inferred) and then have a list of addresses.

The AF indicator could either be done by having a flag in the encoding - or assigning separate code points for each address family.



As an aside, I am wondering what the push is for publishing this as an RFC. Have there been early deployments?

I ask because if you do consider encoding changes, this would obviously impact any existing POCs - but given you did not have early allocation of code point I am wondering if that is a practical issue.

Maybe move forward w an early allocation of code point, get some deployment experience, and then push for an RFC with better experience.



   Les



>

> 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]<mailto:[e-mail]>> On Behalf Of The IESG

> > Sent: Thursday, February 15, 2024 6:22 AM

> > To: IETF-Announce <[e-mail]<mailto:[e-mail]>>

> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]> mailing lists by 2024-02-29. Exceptionally,

> > comments may be sent to [e-mail]<mailto:[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<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/__<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/3331/__>;!

> > !NEt6yMaO-

> gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12NTqD4

> > fHt9pgsqPZaldvVYC2HqNh0$

> >

> >

> >

> >

> >

> >

> > _______________________________________________

> > BIER mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier>

> > __;!!NEt6yMaO-

> gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12N

> > TqD4fHt9pgsqPZaldvVYLcO-qjO$

>

> _______________________________________________

> BIER mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/bier