On 2/20/2018 12:56 PM, arkadiy.gu...@thomsonreuters.com 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
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
