|
Hi Les, I absolutely appreciate your comments and suggestions. I’ve addressed the encoding efficiency issue per your suggestion, but I need to clarify the issue on the router/system-id vs. a routable address. Please see zzh> below.
Juniper Business Use Only From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>
[External Email. Be cautious of content] Jeffrey – I find myself wondering why you are questioning my recommendation. In part, I believe it is because you haven’t implemented the functionality. Zzh> I think the issue is that we have a disconnect on the proposed solution. I am happy to discuss it over the phone or in person in Vancouver, but let me try one more round of email below. 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. Zzh> The RIB (as an example) is not used here as at all. Zzh> There is a post-SPF processing documented in the Section 6.9 of RFC8279 that handles the situation where the next hop router is not BIER capable (call it a non-BFR) – this router will figure out the BIER-capable
(grand-)children of that non-BFR and tunnel to them. Zzh> While that works, individual tunneling may not be desired, and this document optimized that – instead of tunneling to its children, tunnel to its helper. Zzh> So we have this SPF tree calculated and during the post-SPF we’re looking at a child on the tree and want to find out its helper. That child is represented by a corresponding LSA/LSP, which has a router/system-id,
which can be used to look up the helper - if the helper advertised “I am helping someone with this router/system-id” we can build the “router/system-id of the helped node --> BFR-prefix of the helper node” mapping when the advertisement is received. 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. Zzh> At any time for a helper to be helpful, reachability is certainly needed. However, for a helper to announce “I can help X” (ahead of time) the announcement does not need to care about reachability at
the time of advertisement (and it doesn’t withdraw the announcement when it loses the reachability). Zzh> When the calculating router figures out that it has a child X incapable of BIER on the SPF tree, it will look up the mapping to find the helper’s BFR-prefix. If there is a tunnel to that helper and the
helper can reach X’s BFR child (w/o looping back through the calculating router), then it can be used to reach that BFR child. Zzh> I updated the spec to also address comments from Gunter, and the route calculation text is enhanced – please see section 4.1 in the attached draft (not posted yet). In any case, you have my recommendation. Feel free to consult other experts for their opinions. Zzh> Thanks for your review and suggestions on more efficient encoding (and I have taken your suggestion), but I do believe the router/system-id works the best here. If we advertise a routable address instead,
during the post-SPF processing we need to look at each address associated with X and see if there is a helper tied to that address. Using router/system-id is much simpler.
Zzh> Jeffrey Les Juniper Business Use Only 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 |
BIER Z. Zhang
Internet-Draft Juniper Networks
Intended status: Standards Track N. Warnke
Expires: 1 December 2024 Deutsche Telekom
I. Wijnands
Arrcus
D. Awduche
Verizon
30 May 2024
Tethering A BIER Router To A BIER incapable Router
draft-ietf-bier-tether-06
Abstract
This document specifies optional enhancements to optimize the
handling of Bit Index Explicit Replication (BIER) incapable routers
by attaching (tethering) a BIER router to a BIER incapable router,
including procedures and ISIS/OSPF/BGP signaling extensions.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 December 2024.
Zhang, et al. Expires 1 December 2024 [Page 1]
Internet-Draft bier-tether May 2024
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Additional Considerations . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IGP Signaling and Calculation . . . . . . . . . . . . . . 6
4.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Terminology
Familiarity with BIER {{!RFC8279}} architecture, protocols and
procedures is assumed. Some terminologies are listed below for
convenience.
BIER: Bit Indexed Explicit Replication
BFR: BIER Forwarding Router
BFER: BIER Forwarding Egress Router
BFR-prefix: Each BFR is assigned a single "BFR-prefix" for each sub-
domain to which it belongs. It is recommended that the BFR-prefix be
a loopback address of the BFR.
Zhang, et al. Expires 1 December 2024 [Page 2]
Internet-Draft bier-tether May 2024
2. Introduction
Consider the scenario in Figure 1 where router X does not support
BIER. BFER1..n and BFR1..n are BIER capable - implied by their
names.
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
.........
\
------ BFRn ------- BFERn
Figure 1: Deployment with BIER incapable routers
For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to
tunnel individual copies through X. This degrades to "ingress"
replication to those BFRs. If X's connections to BFRs are long
distance or bandwidth limited, and n is large, it becomes very
inefficient.
A solution to the inefficient tunneling is to attach (tether) a BFRx
to X as depicted in Figure 2:
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
/ \ .........
/ \
BFRx ------ BFRn ------- BFERn
Figure 2: Tethered BFRx
Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get
BIER packets to BFRx, which will then tunnel to BFR2, ..., BFRn.
There could be fat and local pipes between the tethered BFRx and X,
so ingress replication from BFRx is acceptable.
For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to
be announced in Interior Gateway Protocol (IGP) as a forwarding
adjacency so that BFRx will appear on the Shortest Path First (SPF)
tree. This needs to happen in a BIER specific topology so that
unicast traffic would not be tunneled to BFRx. Obviously this is
operationally cumbersome.
Zhang, et al. Expires 1 December 2024 [Page 3]
Internet-Draft bier-tether May 2024
Section 6.9 of the BIER architecture specification [RFC8279]
delineates a methodology for tunneling BIER packets through incapable
routers without the need to explicitly announce tunnels.
Nonetheless, this method is inapplicable in the current context, as
BFRx is not a node in the SPF tree rooted at BFR1
There is a simple solution to the problem though. BFRx could
advertise that it is X's helper and other BFRs will use BFRx (instead
of X's children on the SPF tree) to replace X during its post-SPF
processing as described in section 6.9 of BIER architecture
specification [RFC8279].
3. Additional Considerations
While the scenario in Figure 2 has a local connection between BFRx
and X, it does not have to be like that. As long as BIER packets can
be tunneled to BFRx without requiring X to do BIER forwarding and
BFRx will not send them back to X's upstream BFR, the tethering
solution works.
Additionally, the helper BFRx can be a transit helper, i.e., it has
other connections (instead of being a stub helper that is only
connected to X), as long as BFRx won't send BIER packets tunneled to
it back to the tunnel ingress. Figure 3 below is an example
topology:
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
|
|
BFRx ------ BFR4 ------- BFER4
\
------ BFR5 ------- BFER5
Figure 3: A Safe Transit Helper
In the above example, BFR1 can tunnel one copy to BFRx, which will
tunnel to BFR2/BFR3 and send natively to BFR4/BFR5 respectively.
In the example of Figure 4, there is a connection between BFR1 and
BFRx. If the link metrics are all 1 on the three sides of
BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3
while the other two sides of the triangle have metric 1 then BFRx
will send BIER packets tunneled to it from BFR1 back to BFR1, causing
a loop.
Zhang, et al. Expires 1 December 2024 [Page 4]
Internet-Draft bier-tether May 2024
------ BFR2 ------- BFER2
/
BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3
\ / \ .........
\ / \
BFRx ------ BFRn ------- BFERn
Figure 4: Potential looping situation
This can easily be prevented if BFR1 does an SPF calculation with the
helper BFRx as the root. For any BFERn reached via X from BFR1, if
BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the
helper. Instead, BFR1 must directly tunnel packets for BFERn to X's
BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of
[RFC8279].
Notice that this SPF calculation on BFR1 with BFRx as the root is not
different from the SPF done for a neighbor as part of Loop-Free
Alternate (LFA) calculation. In fact, BFR1 tunneling BIER packets to
X's helper is not different from tunneling unicast packets to a TI-
LFA backup.
Also notice that, instead of a dedicated helper BFRx, any one or
multiple ones of BFR2..n can also be the helper (as long as the
connection between that BFR and X has enough bandwidth for
replication to multiple helpers through X). To allow multiple
helpers to help the same non-BFR, the "I am X's helper" advertisement
carries a priority. BFR1 will choose the helper advertising the
highest priority among those satisfying the loop-free condition
described above. When there are multiple helpers advertising the
same priority and satisfying the loop-free condition, any one or
multiple ones could be used solely at the discretion of BFR1.
However, if multiple ones are used, it means that multiple copies may
be tunneled through X.
The tethering solution works for the situation in Figure 5 as well,
where a helper BFRxy helps two different non-BFRs X and Y.
Zhang, et al. Expires 1 December 2024 [Page 5]
Internet-Draft bier-tether May 2024
----- BFR2 ------- BFER2
/
X ------- BFR3 ------- BFER3
/ | \
/ \ ----- BFR4 ------- BFER4
/ \
BFER1 -- BFR1 BFRxy ------------- BFERxy
\ /
\ / ----- BFR5 ------- BFER5
\ | /
Y ------- BFR6 ------- BFER6
\
----- BFRn ------- BFERn
Figure 5: One Helper for multiple helped
4. Specification
The procedures in this document apply when a BFRx is tethered to a
BIER incapable router X as X's helper for BIER forwarding.
4.1. IGP Signaling and Calculation
Suppose that the BIER domain uses BIER signaling extensions to ISIS
[RFC8401] or OSPF [RFC8444] [draft-ietf-bier-ospfv3-extensions]. A
helper node (BFRx) MUST advertise a BIER Helped Node sub-sub-TLVs in
the BIER Info sub-TLV in the case of ISIS or a BIER Helped Node sub-
TLV in the BIER sub-TLV in the case of OSPFv2/OSPFv3:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of <System-ID, Priority> for the Helped Nodes (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ISIS BIER Helped Node sub-sub-TLV
Zhang, et al. Expires 1 December 2024 [Page 6]
Internet-Draft bier-tether May 2024
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of <Router-ID, Priority> for the Helped Nodes (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: OSPF BIER Helped Node sub-TLV
The Type is TBD1 in the case of ISIS, TBD2 in the case of OSPFv2, or
TBD3 in the case of OSPFv3, to be assigned by IANA.
In the case of ISIS, the Value field is a list of <6-octet ISIS
System-ID, 1-octet Priority> tuples, one for each helped node. The
number of tuples is derived from the Length field of the sub-sub-TLV.
In the case of OSPFv2 or OSPFv3, the Value field is a list of
<4-octet OSPF Router-ID, 1-octet Priority> tuples, one for each
helped node. The number of tuples is derived from the Length field
of the sub-TLV.
When there are more than one helper nodes for a helped non-BFR node,
the helper advertising a higher priority MUST be preferred. If there
are multiple helpers advertising the same priority, ECMP through
those equal-priority helpers MAY be used.
The post-SPF processing procedures in Section 6.9 of the BIER
architecture specification [RFC8279] are modified as follows for BIER
tethering purpose.
(1) BFR-B looks in turn at each of its child nodes on the BIER-SPF
tree.
(2) If one of the child nodes, say X, does not support BIER, BFR-B
removes X from the tree. The child nodes of X that has just
been removed are then re-parented on the tree, so that BFR-B now
becomes their parent. Each child of X that is re-parented, say
Cx, maintains an ordered list of nodes and X is added to that
list. It is possible that X itself may be a re-parented child
and has a non-empty list already. In that case, X's list is
copied to Cx, and X is added to the end of the list.
(3) BFR-B then continues to look at each of its child nodes,
including any nodes that have been re-parented to BFR-B as a
result of the previous step.
Zhang, et al. Expires 1 December 2024 [Page 7]
Internet-Draft bier-tether May 2024
At the end of the above iterations, BFR-B's children on the BIER-SPF
tree will all be BFRs. Some of them may be non-adjacent (not
directly connected to BFR-B) and BFR-B could just tunnel to them as
described in Section 6.9 of [RFC8279], i.e., without the tethering
benefit.
A non-adjacent child has a non-empty list built in Step 2, which is a
list of BIER-incapable nodes between BFR-B and the child. That list
is used for the tethering purposes as follows.
For each non-adjacent child (with a non-empty list), the following
additional procedures are performed:
* Starting with the first node in the ordered list of incapable
nodes, say N1, check if there is one or more helper nodes for N1.
If not, go to the next node in the list.
* Order all the helper nodes of N1 based on descending (priority,
BFR-prefix). Starting with the first one, say H1, check if BFR-B
could use H1 as LFA next hop to reach the child. If yes,
tunneling to H1 (which is a helper to a node upstream of the
child) instead of to the child itself can be used and the
procedure stops for the child unless there is another helper in
the list with the same priority (in which case ECMP could be
used). Otherwise, go to the next helper in order and repeat.
* If none of the helper nodes of N1 can be used, go to the next node
in the list of incapable nodes and repeat.
If the above procedure finishes without finding any usable helper,
then direct tunneling to the child has to be used to reach the BFER.
Notice that only the building and use of the list for the non-
adjacent children are the extensions to the original Section 6.9
procedures.
4.2. BGP Signaling
Suppose that the BIER domain uses BGP signaling
[I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..n advertise
BFR-prefixes that are reachable through them, with BIER Path
Attributes (BPA) attached. There are two situations regarding X's
involvement:
(1) X does not participate in BGP peering at all
(2) X re-advertises the BFR-prefixes but it does not update the BPA.
Zhang, et al. Expires 1 December 2024 [Page 8]
Internet-Draft bier-tether May 2024
In either case, the BFR1..n will tunnel BIER packets directly to each
other. This may not be desired as explained earlier.
To make BFR1 tunnel one copy to BFRx which then tunnel to BFR2...n,
the following can be done in the case of BGP (no new signaling is
needed):
* Configure BGP sessions between X and BFR1..n and BFRx.
* BFRx advertises its own BFR-prefix with BPA to X, and sets the
BIER Nexthop to itself.
* When X re-advertises BFR-prefixes to its helper BFRx, it does not
change the BPA. This allows BFRx to tunnel BIER packets to
BFR1..n.
* When X re-advertises BFR-prefixes to BFR1..n, it replaces the BPA
with the one attached to BFRx's BFR-prefix. Notice that if X
supported BIER forwarding, it'd re-advertise the BFR-prefixes with
its own BPA so that BFR1..n would send BIER traffic to itself.
Since X does not BIER forwarding, using BFRx's BPA instead allows
BFR1..n to tunnel BFRx.
5. Security Considerations
This specification does not introduce additional security concerns
beyond those already discussed in BIER architecture and OSPF/ISIS/BGP
extensions for BIER signaling.
6. IANA Considerations
This document requests a new sub-sub-TLV type value from the "Sub-
sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV
Codepoints" registry:
Type Name
---- ----
TBD1 BIER Helped Node
This document requests a new sub-TLV type value from the OSPFv2
Extended Prefix TLV Sub-TLV registry:
Type Name
---- ----
TBD2 BIER Helped Node
This document also requests a new sub-TLV type value from the OSPFv3
Extended-LSA Sub-TLVs registry:
Zhang, et al. Expires 1 December 2024 [Page 9]
Internet-Draft bier-tether May 2024
Type Name
---- ----
TBD3 BIER Helped Node
7. Contributors
The following also contributed to this document.
Zheng(Sandy) Zhang
ZTE Corporation
EMail: zzhang_ietf@xxxxxxxxxxx
Hooman Bidgoli
Nokia
EMail: hooman.bidgoli@xxxxxxxxx
8. Acknowledgements
The author wants to thank Eric Rosen and Antonie Przygienda for their
review, comments and suggestions.
9. Normative References
[I-D.ietf-bier-idr-extensions]
Xu, X., Chen, M., Patel, K., Wijnands, I., Przygienda, T.,
and Z. J. Zhang, "BGP Extensions for BIER", Work in
Progress, Internet-Draft, draft-ietf-bier-idr-extensions-
10, 13 June 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-bier-idr-extensions-10>.
[I-D.ietf-bier-ospfv3-extensions]
Psenak, P., Nainar, N. K., and I. Wijnands, "OSPFv3
Extensions for BIER", Work in Progress, Internet-Draft,
draft-ietf-bier-ospfv3-extensions-07, 1 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-bier-
ospfv3-extensions-07>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Zhang, et al. Expires 1 December 2024 [Page 10]
Internet-Draft bier-tether May 2024
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z.
Zhang, "Bit Index Explicit Replication (BIER) Support via
IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018,
<https://www.rfc-editor.org/info/rfc8401>.
[RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A.,
Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2
Extensions for Bit Index Explicit Replication (BIER)",
RFC 8444, DOI 10.17487/RFC8444, November 2018,
<https://www.rfc-editor.org/info/rfc8444>.
Authors' Addresses
Zhaohui Zhang
Juniper Networks
Email: zzhang@xxxxxxxxxxx
Nils Warnke
Deutsche Telekom
Email: Nils.Warnke@xxxxxxxxxx
IJsbrand Wijnands
Arrcus
Email: ice@xxxxxxxxxxxx
Daniel Awduche
Verizon
Email: daniel.awduche@xxxxxxxxxxx
Zhang, et al. Expires 1 December 2024 [Page 11]
<<< text/html; name="draft-ietf-bier-tether-06.diff.html": Unrecognized >>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
