|
Jeffrey – I find myself wondering why you are questioning my recommendation. In part, I believe it is because you haven’t implemented the functionality. The point about reachability is telling. If the internal BIER component wants to determine if a particular node is reachable, the internal data structures (e.g., RIB) aren’t
going to have an entry for the IS-IS system id. They will, however, have an entry for the router address/router ID if it is reachable. And I don’t know why a helper node would want to advertise it can be a helper for a node that isn’t reachable. In any case, you have my recommendation. Feel free to consult other experts for their opinions. Les From: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>
Hi Less, We don’t need them to be routable. As I explained: Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child
has the router/system-id in it, and the ID can be used to look up the helper. In an OSPF/ISIS network, each node has a router/system-id. When an operator provisions a helper to help a node that is not BIER capable, it is feasible and easy to enter the router/system-id
of the helped node. Thanks. Jeffrey Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
[External Email. Be cautious of content] (Top posting) Jeffrey – Why don’t we want to use OSPF router id/IS-IS system id? Because they are not routable IDs. Routers will not have forwarding entries for these identifiers – so it won’t be easy to determine whether these nodes are reachable. The OSPF Router Address and the IS-IS TE Router IDs were invented precisely to provide stable routable addresses for a node. They are now being used in numerous ways to identify the source of information e.g.,
https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2 https://www.rfc-editor.org/rfc/rfc9084.html#name-prefix-source-router-addres Your use case is best supported by using these identifiers. Les Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang@xxxxxxxxxxx>
Hi Les, Please see zzh3> beow. Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
[External Email. Be cautious of content] Jeffrey – Please find my responses inline. Look for LES2: Juniper Business Use Only From: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@xxxxxxxxxxxxxx>
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? [LES2:] For IS-IS you should use the TE Router ID as defined in RFC5305, RFC6119 For OSPF you should use the Router Address as defined in RFC3630, RFC5329. Zzh3> What about using the 32-bit router-id for OSPF, and the 48-bit system-id in the ISIS case? Zzh3> The information is used during the post-SPF process – if a child of the SPF tree root does not support BIER, we try to see if it has a helper that can be used. The LSA/LSP for the child
has the router/system-id in it, and the ID can be used to look up the helper. Zzh3> What do you think? Zzh3> Thanks. Zzh3> Jeffrey > 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. [LES2:] I assume you will revisit this answer based on my reply above regarding the addresses to be used. 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. [LES2:] The hallmark of the IETF is that we define solutions which actually work. The way that is achieved is that we implement the proposed solutions BEFORE documents progress to RFC. This is not meant to imply that your idea cannot work. But how do we know if it works and if the encodings defined to support it are both sufficient and optimal? This is knowledge that we want to gain BEFORE standardization. Otherwise, we are likely to end up with early deployments which can constrain corrections in the encodings due to backwards compatibility considerations. I take your point (made in response to Gunter’s review) that performant BIER implementations depend on new ASICs. But this does not mean that we cannot implement POCs which operate at low scale but still allow us to refine the
specification based on actual testing. I really think you should take the inputs received, focus on implementation, and come back to the WG with feedback based on the experience gained. No need to standardize an unproven solution prematurely. Les 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
