Re: [Idr] draft-ietf-idr-bgpls-srv6-ext - 2 week Early Allocation Call [6/2 - 6/16/2019]

["Susan Hares" <[e-mail]>]

Acee:

 

Good question.   There is clear interest in implementing these drafts, and lots of valuable input on the drafts has been accepted.  

 

Per https://tools.ietf.org/html/rfc7120#section-3.1,  (which refers to section 2 text below), the WG needs to determine:  clear technical specification, stability, and interest in implementation.    While John and I feel these drafts are ready for early allocation, some WG members may have a good technical reason for considering the draft to be “unclear” or “unstable”.   A 2 week WG call provides the period for comment (public or private) to the WG chairs.   After that, Alvaro usually makes his determination within week.   

 

IDR used to have more volatile arguments, but as IDR WG chairs (like LSR) allow the period of comments – the volatile arguments seem to have diminished.   

 

Sue 

 

----------------------------------

Per section 2 of RFC7120: 

 

 <https://tools.ietf.org/html/rfc7120#section-2> 2.  Conditions for Early Allocation

   The following conditions must hold before a request for early

   allocation of code points will be considered by IANA:

 

   a.  The code points must be from a space designated as "RFC

       Required", "IETF Review", or "Standards Action".  Additionally,

       requests for early assignment of code points from a

       "Specification Required" registry are allowed if the

       specification will be published as an RFC.

 

   b.  The format, semantics, processing, and other rules related to

       handling the protocol entities defined by the code points

       (henceforth called "specifications") must be adequately described

       in an Internet-Draft.

 

   c.  The specifications of these code points must be stable; i.e., if

       there is a change, implementations based on the earlier and later

       specifications must be seamlessly interoperable.

 

   d.  The Working Group chairs and Area Directors (ADs) judge that

       there is sufficient interest in the community for early (pre-RFC)

       implementation and deployment, or that failure to make an early

       allocation might lead to contention for the code point in the

       field.

 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Acee Lindem (acee)
Sent: Monday, June 3, 2019 7:42 AM
To: Ketan Talaulikar (ketant); Susan Hares; [e-mail]
Cc: [e-mail]
Subject: Re: [Idr] draft-ietf-idr-bgpls-srv6-ext - 2 week Early Allocation Call [6/2 - 6/16/2019]

 

I support as well. However, I wondering why the IDR WG goes through the formality of additional code point allocation call given that the document is already a WG document and has gone through an adoption call. It would seem very strange to me to accept a document as a WG document and yet deny early code point allocation. 

Thanks,
Acee

 

From: Idr <[e-mail]> on behalf of "Ketan Talaulikar (ketant)" <[e-mail]>
Date: Monday, June 3, 2019 at 2:05 AM
To: Susan Hares <[e-mail]>, IDR List <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Idr] draft-ietf-idr-bgpls-srv6-ext - 2 week Early Allocation Call [6/2 - 6/16/2019]

 

Hi Sue/All,

 

Support as a co-author to enable implementation of this draft to support SRv6 use-cases.

 

Thanks,

Ketan 

 

From: Susan Hares <[e-mail]> 
Sent: 03 June 2019 07:57
To: Ketan Talaulikar (ketant) <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: draft-ietf-idr-bgpls-srv6-ext - 2 week Early Allocation Call [6/2 - 6/16/2019]

 

This begins a 2 week Early Allocation call for parameters from: 

 

 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-00

 

The authors are requesting for early code point allocation from 

IANA to enable implementations with suggested code points as indicated below.

 

The criteria for early allocation includes:  stable working group document, 

clear technical solution and implementation interest.   The IDR chairs 

believe this document meets these criteria. Please let us know if you 

think this draft meets these criteria. 

 

If you support early adoption,  please include “support” in your along

with any comments about the draft’s technical solution.  Since the 

authors are heading into testing implementations, any comments about

error or improvements will be helpful to the authors.  

 

If you do not support early allocation, please include 

include “no support in your email” and indicate why. 

 

Cheerily, Sue Hares  

 

----------------------

 

   The following codepoints is suggested (to be assigned by IANA) from

   within the sub-registry called "BGP-LS NLRI-Types":

 

    +------+----------------------------+---------------+

    | Type | NLRI Type                  |   Reference   |

    +------+----------------------------+---------------+

    |  6   | SRv6 SID                   | this document |

    +------+----------------------------+---------------+

 

   The following TLV codepoints are suggested (to be assigned by IANA)

   from within the sub-registry called "BGP-LS Node Descriptor, Link

   Descriptor, Prefix Descriptor, and Attribute TLVs":

 

   +----------+----------------------------------------+---------------+

   | TLV Code |             Description                | Value defined |

   |  Point   |                                        |       in      |

   +----------+----------------------------------------+---------------+

   |  1038    |   SRv6 Capabilities TLV                | this document |

   |  1106    |   SRv6 End.X SID TLV                   | this document |

   |  1107    |   IS-IS SRv6 LAN End.X SID TLV         | this document |

  |  1108    |   OSPFv3 SRv6 LAN End.X SID TLV        | this document |

   |  1162    |   SRv6 Locator TLV                     | this document |

   |   518    |   SRv6 SID Information TLV             | this document |

   |  1250    |   SRv6 Endpoint Function TLV           | this document |

   |  1251    |   SRv6 BGP Peer Node SID TLV           | this document |

   +----------+----------------------------------------+---------------+