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

[IJsbrand Wijnands <[e-mail]>]

Hi Jeffrey,

> 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.

ICE: Yes, I think this proposal has merit and a possible consensus for those who prefer to align with IGP and those who like to have BIER specific algorithms.

>  
> 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.

ICE: In write up below its more clear on what BARM is, maybe change the name to make it more explicit this is the IGP Algorithm registry. Maybe call it BIER IGP AlgoriThm (BIAT)?

>  
> 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.

ICE: Ok, I like that. Both values are independent of each other. This means the developments for both BIER Algorithm and IGP Algorithm can move forward without blocking each other.

>  
> Future specifications may specify BART values that change the
> interpretation of the BARM octet. Those specifications must handle backwards

ICE: This creates a potential dependency which I think we should avoid. I think there are possible use-cases where the combination of the two values could be valuable. But since we don’t yet know what that is, lets not speculate on it. Let keep both values as equal importance without interdependency.

> 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

ICE: We should probably create a registry for BIAT, and make clear in the draft the values are identical to the IGP Algorithm registry. In an ideal world we would like to point to it, but that might get the draft stuck. Or, if there are other ideas on how to deal with that, would be good to know...

> Comments?

I think this is good, making the two values of equal importance makes sure nobody is blocked on each other and we can move on.

Thanks Jeffrey,

Ice.

>  
> 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] 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.
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier