Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

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:[e-mail]] On Behalf Of Eric C Rosen
Sent: Tuesday, February 20, 2018 2:43 PM
To: [e-mail] <[e-mail]>; [e-mail]; [e-mail]
Cc: [e-mail]
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, [e-mail]<mailto:[e-mail]> 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.