When I said I prefer Option B earlier, I was actually referring to something
similar to what was discussed below between Eric and Arkadiy, though with some
differences.
Whether we call it Option F or whatever, I have the following text prepared for
everyone to review and comment. Ironically, I started with the OSPF spec J
2.1. BIER 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-domain-ID | MT-ID | BFR-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BART | BARM | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
BART: A single-octet specifying the Bier AlgoRiThm used to calculate underlay
paths to reach BFERs. Values are allocated from the BIER Algorithm
Registry.
Value 0 indicates the basic Shortest Path First algorithm using IGP metric.
BARM: A single-octet specifying the BIER AlgoRithm Modififer that can be used
to either modify, enhance or replace calculation of underlay paths to
reach BFERs as defined by the BART value.
In this document version, both the BART and BARM octets MUST be zero. If an
implementation based on this document receives a non-zero BART or BARM octet,
it MUST treat it as an error and ignore the received BIER sub-TLV.
BART and BARM are independent of each other, and the BARM value identify
an IGP Algorithm (either those 0~128 values registered in the “IGP Algorithm
Type”
registry, or a number that identifies a Flexible Algorithm [<reference here>],
which is also considered as an IGP Algorithm.
Future specifications may specify BART values that change the
interpretation of the BARM octet. Those specifications must handle backwards
compatibility issues (or simply declare that backwards compatibility is not
required - the deployment will then require the operator to make sure that all
routers in the subdomain conform to the same specification).
[note that will not be added to the spec: if someone wants define a BART value
in the future that changes the meaning of BARM, he would need
to write a spec to explicitly state that and get the spec approved. W/o that,
the BARM field is always interpreted as an IGP Algorithm]
4. IANA Considerations
IANA is requested to set up a registry called "BIER Algorithm Registry".
The registration policies for this registry are
* "Standards Action" ([RFC5226] and [RFC7120]) for values 0-240
* "Experimental Use" for values 240-255
The initial values in the BIER Algorithm Registry are:
0: Shortest Path First (SPF) algorithm based on IGP link metric
1-255: Unassigned
Comments?
Jeffrey
From: BIER [mailto:[email protected]] On Behalf Of Eric C Rosen
Sent: Tuesday, February 20, 2018 2:43 PM
To: [email protected] <[email protected]>;
[email protected]; [email protected]
Cc: [email protected]
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and
draft-ietf-bier-ospf-extensions
On 2/20/2018 12:56 PM,
[email protected]<mailto:[email protected]> wrote:
I personally like Eric proposed option -two independed 1Byte filed one for IGP
Algo and another one for BUAM : the "BIER Underlay Algorithm Modifier"
registry. The way the underlay paths are computed for a given BIER sub-domain
is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER
Underlay Algorithm Modifier codepoint>.
Not sure why it is not in a list of proposed options since I saw a lot of
support for it on the WG.
It sort of Option-B but allow more independence between BAR(BUAM) from IGP Algo
I'm also wondering what's wrong with this proposal as a way of moving forward.
The only real change I'd make to it is that the first one-octet field would
either be a codepoint from the IGP Algorithms registry or a Flex-Algo
codepoint. Since the former are in the range 1-127 and the latter in the range
128-254, no ambiguity is possible.
With regard to the question of why it makes sense to use an IGP Algorithms
codepoint, I think the argument is the following. Per the architecture, BIER
relies on a routing underlay to tell it the next hop for a given BFER. Per the
architecture, the routing underlay may use the exact same decision procedure
applied to the exact same topology as can be applied for unicast routing. One
way of identifying a unicast routing decision procedure is with codepoints
from the IGP Algorithms registry and/or Flex-Algo codepoints. Thus it makes
sense for the IGP signaling to use these codepoints as a way of providing the
BIER layer information about the routing underlay.
With regard to the question of why it makes sense to have a second one-octet
BIER-specific field, I think the argument is the following. The architecture
does not require BIER to use a routing underlay that applies a decision
procedure that is useful for or even applicable to unicast packets. In such a
case, there might not be a way to identify the decision procedure with a
codepoint from the IGP Algorithms registry or even with a Flex-Algo codepoint.
So it's useful to have a codepoint that does not have to hold values from the
IGP Algorithms registry and does not need to have Flex-Algo codepoints.
There is also some worry that there may in the future be a lot of arguments
about populating IGP Algorithms registry, and it would be good to have a way to
extend BIER by allocating codepoints that help identify the routing underlay,
but that might not be useful for unicast applications.
To some extent, this is all a tempest in a teapot, because the extensible TLV
structure can be used, as Alia points out, to work around any codepoint
problems. Of course, continually adding TLVs to modify the interpretation of
other TLVs can becomes a problem in itself.
I think the most compelling argument for adding the second codepoint field is
that it provide more options for exploring the issues that might arise as
production deployments begin.
I don't believe that any field containing a codepoint should ever be created
without an association to a registry. That makes squatting and future
codepoint clash inevitable.
Thus I think the current documents, which have a one-octet field that is not
associated with a registry at all, are not really acceptable. So I don't see
any way to move forward now other than with a compromise like the one I
suggested. This is not exactly Alia's option B, because the second codepoint
is not properly thought of as a sub-type of the other.
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
