|
Jeffrey - Thanx for the prompt response. (Better than me.
😊) Please see inline. > -----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. > 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 <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 https://www.ietf.org/mailman/listinfo/last-call
