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

This is a multi-part message in MIME format.
--===============2317989761457969368==
Content-Type: multipart/alternative;
 boundary="------------0269CDB0E18277A57612A68B"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------0269CDB0E18277A57612A68B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2/20/2018 12:56 PM, [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.


--------------0269CDB0E18277A57612A68B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 2/20/2018 12:56 PM, <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
    <blockquote type="cite"
      cite="mid:[email protected]">
      <p class="MsoNormal"><span style="color:black">I personally like
          Eric proposed option -two independed 1Byte filed one for IGP
          Algo and another one for BUAM :
        </span><span style="font-size:12.0pt;font-family:&quot;Times New
          Roman&quot;,serif;color:black">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: &lt;IGP Algorithms codepoint, BIER Underlay
          Algorithm Modifier codepoint&gt;.<o:p></o:p></span></p>
      <p class="MsoNormal"><span style="color:black">Not sure why it is
          not in a list of proposed options since I saw a lot of support
          for it on the WG.</span><o:p></o:p></p>
      <p class="MsoNormal"><span style="color:black">It sort of Option-B
          but allow more independence between BAR(BUAM) from IGP Algo</span></p>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    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.<br>
    <br>
  </body>
</html>

--------------0269CDB0E18277A57612A68B--


--===============2317989761457969368==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg

--===============2317989761457969368==--