|
Hi Les,
Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>
[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@xxxxxxxx> On Behalf Of Jeffrey (Zhaohui) Zhang > Sent: Monday, April 8, 2024 7:03 AM > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>;
last-call@xxxxxxxx; IETF- > Announce <ietf-announce@xxxxxxxx> > Cc: andrew-ietf@xxxxxxxxxxx;
bier-chairs@xxxxxxxx;
bier@xxxxxxxx; > chen.ran@xxxxxxxxxx;
draft-ietf-bier-tether@xxxxxxxx > 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@xxxxxxxxx> > Sent: Friday, April 5, 2024 6:36 PM > To: last-call@xxxxxxxx; IETF-Announce <ietf-announce@xxxxxxxx> > Cc: andrew-ietf@xxxxxxxxxxx;
bier-chairs@xxxxxxxx;
bier@xxxxxxxx; > chen.ran@xxxxxxxxxx;
draft-ietf-bier-tether@xxxxxxxx > 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@xxxxxxxx> On Behalf Of The IESG > > Sent: Thursday, February 15, 2024 6:22 AM > > To: IETF-Announce <ietf-announce@xxxxxxxx> > > Cc: andrew-ietf@xxxxxxxxxxx;
bier-chairs@xxxxxxxx;
bier@xxxxxxxx; > > chen.ran@xxxxxxxxxx;
draft-ietf-bier-tether@xxxxxxxx > > 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@xxxxxxxx mailing lists by 2024-02-29. Exceptionally, > > comments may be sent to
iesg@xxxxxxxx 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 > > BIER@xxxxxxxx > >
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > __;!!NEt6yMaO- > gk!BSZTXoy3BEXySKhAl4dKYN2L8dwwp78mkXJMt7S8Qz44ePY-vB12N > > TqD4fHt9pgsqPZaldvVYLcO-qjO$ > > _______________________________________________ > BIER mailing list |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
