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

Hi Les,

Juniper Business Use Only
From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>
Sent: Monday, April 8, 2024 12:20 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; last-call@ietf.org; IETF-Announce <ietf-announce@ietf.org>
Cc: andrew-ietf@liquid.tech; bier-chairs@ietf.org; bier@ietf.org; chen.ran@zte.com.cn; draft-ietf-bier-tether@ietf.org
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]

Jeffrey -

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

Please see inline.

Zzh2> Well this time it took me more than a month to get back. Sorry about that. Lots of catching-up on the backlog from business/vacation travels.

Juniper Business Use Only
> -----Original Message-----

> From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Jeffrey (Zhaohui) Zhang

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

> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; last-call@ietf.org<mailto:last-call@ietf.org>; IETF-

> Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

> 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) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>

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

> To: last-call@ietf.org<mailto:last-call@ietf.org>; IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

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

Zzh2> Good point; and I do need your advice on this one.

Zzh2> For OSPF, it’s always 32-bit. For ISIS, I see three possibilities: system-id, IPv4 router-id and IPv6 router-id.

Zzh2> The router-id concept is introduced into ISIS with TE. Is it a common practice now to always advertise an IPv4 and/or IPv6 router-id, w/ or w/o TE? Should I simply advertise the system-id in the helped-node sub-TLV?

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

Zzh2> That is a good point.

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

Zzh2> I will remove the reserved field.

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.

Zzh2> One helper helping multiple nodes is not a common situation. Still, I will take your advice to pack multiple ones into a single sub-TLV.

Zzh2> We don’t need an AF indicator for OSPF (since the router-id is always 32-bit) or ISIS if we advertise system-id instead.

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.

Zzh2> While there is no deployment yet, the solution is sound and it is just a small extension to the Section 6.9 procedures in RFC8279. If I can get past the reviews by Chris, you, and Gunter, I will still prefer to proceed.

Zzh2> I am happy to have a conference call to discuss the solution in more details.

Zzh2> Thanks!

Zzh2> Jeffrey

   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 <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of The IESG

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

> > To: IETF-Announce <ietf-announce@ietf.org<mailto:ietf-announce@ietf.org>>

> > Cc: andrew-ietf@liquid.tech<mailto:andrew-ietf@liquid.tech>; bier-chairs@ietf.org<mailto:bier-chairs@ietf.org>; bier@ietf.org<mailto:bier@ietf.org>;

> > chen.ran@zte.com.cn<mailto:chen.ran@zte.com.cn>; draft-ietf-bier-tether@ietf.org<mailto:draft-ietf-bier-tether@ietf.org>

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

> > last-call@ietf.org<mailto:last-call@ietf.org> mailing lists by 2024-02-29. Exceptionally,

> > comments may be sent to iesg@ietf.org<mailto:iesg@ietf.org> 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

> > BIER@ietf.org<mailto:BIER@ietf.org>

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

> BIER@ietf.org<mailto:BIER@ietf.org>

> https://www.ietf.org/mailman/listinfo/bier<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!BIfUCpxrA0AT2jNR8bR1jM2-oGiTE9sVzQNnWu0D0-059h4vwGobm758B_07PC9Q2PDcNDkNPSdqPJedUY6hKDSpNA7pbN8N$>