Re: [OSPF] [IANA #986195] Re: Last Call: <draft-ietf-ospf-segment-routing-extensions-19.txt> (OSPF Extensions for Segment Routing) to Proposed Standard

[Peter Psenak <[e-mail]>]

Hi Acee,

can you please ask for early IANA allocation for following values from 
OSPF OSPF Router Information (RI) TLVs Registry:

o 14 - SR Local Block TLV

o 15 - SRMS Preference TLV

We had to change them twice already, as other drafts are taking the values.

thanks,
Peter

  On 27/11/17 20:02 , Amanda Baber via RT wrote:
> Hi Peter,
>
> On Mon Nov 27 19:00:23 2017, [e-mail] wrote:
>> Hi Amanda,
>>
>> thanks for your response. I'm familiar with the early INAA allocation
>> procedures.
>>
>> The question is whether it makes sense to do the early allocation when
>> the draft-ietf-ospf-segment-routing-extensions is already submitted to
>> IESG for publication?
>
> That I don't know, but we have no other way to reserve those specific values.
>
> thanks,
> Amanda
>
>> thanks,
>> Peter
>>
>> On 27/11/17 19:53 , Amanda Baber via RT wrote:
>>> Hi Peter,
>>>
>>> About reserving values:
>>>
>>> On Mon Nov 27 11:58:57 2017, [e-mail] wrote:
>>>> Hi,
>>>>
>>>> I have updated the text.
>>>>
>>>> Looks like there is a conflict in the "OSPF OSPF Router Information
>>>> (RI)
>>>> TLVs Registry" for value 13, which we used in
>>>> draft-ietf-ospf-segment-routing-extensions, but has been assigned to
>>>> "Tunnel Encapsulations" (ietf-ospf-encapsulation-cap-09) in the
>>>> meantime.
>>>>
>>>> I have updated the value in draft-ietf-ospf-segment-routing-
>>>> extensions
>>>> to use value 15 instead.
>>>>
>>>> I would also like to ask IANA to reserve values 14 and 15 in the
>>>> "OSPF
>>>> OSPF Router Information (RI) TLVs Registry" to prevent them being
>>>> taken
>>>> by other drafts while the draft-ietf-ospf-segment-routing-extensions
>>>> is
>>>> waiting for publication.
>>>
>>> We can't reserve values, but we can make early allocations, as
>>> described in RFC 7120 (see Section 3 for information about requesting
>>> one). In order to do so, we would need a request from a chair, with
>>> the AD's approval. The allocation would last for one year, but could
>>> be renewed for one more year by the chairs and AD. Any further
>>> renewals would have to be approved by the IESG. We would make the
>>> registration permanent upon approval of the document listed as the
>>> reference.
>>>
>>> If one of the chairs is going to submit an early allocation request,
>>> please send a separate email to [e-mail], without this ticket
>>> number in the subject line.
>>>
>>> For future reference, if this were a First Come First Served or
>>> Expert Review registry -- i.e. a registry that doesn't require RFC
>>> publication -- we would ask you to submit a request for permanent
>>> registration. Temporary allocation isn't available for registries
>>> that don't require an RFC for registration.
>>>
>>> thanks,
>>> Amanda
>>>
>>>> thanks,
>>>> Peter
>>>>
>>>> On 20/11/17 14:19 , Acee Lindem (acee) wrote:
>>>>> Hi Peter,
>>>>> The only thing I might add is that the new “IGP Algorithm Type”
>>>>> registry
>>>>> should be under a new broader category of “Interior Gateway
>>>>> Protocol (IGP)
>>>>> Parameters” IANA registries.
>>>>> Thanks,
>>>>> Acee
>>>>>
>>>>> On 11/20/17, 4:58 AM, "Peter Psenak (ppsenak)" <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Hi Acee,
>>>>>>
>>>>>> ok, so I assume what is currently in the draft is correct.
>>>>>>
>>>>>> thanks,
>>>>>> Peter
>>>>>>
>>>>>> On 08/11/17 13:46 , Acee Lindem (acee) wrote:
>>>>>>> Peter, Amanda,
>>>>>>>
>>>>>>> Let’s go with an IGP Algorithms Registry in a broader class of
>>>>>>> IGP
>>>>>>> Parameters. OSPF and IS-IS are the only places we know we’ll use
>>>>>>> the
>>>>>>> algorithms immediately.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Acee
>>>>>>>
>>>>>>> On 11/8/17, 3:51 AM, "Peter Psenak (ppsenak)" <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Alia, Acee,
>>>>>>>>
>>>>>>>> have we concluded whether we define a registry under OSPF and
>>>>>>>> use it
>>>>>>>> elsewhere, or we define a protocol independent one?
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> On 08/11/17 08:14 , Amanda Baber via RT wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Has a name been chosen? Should it be included in the IANA
>>>>>>>>> Considerations section?
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>> Amanda
>>>>>>>>>
>>>>>>>>> On Thu Oct 26 10:03:09 2017, [e-mail] wrote:
>>>>>>>>>> Hi Alia,
>>>>>>>>>>
>>>>>>>>>> From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Date: Thursday, October 26, 2017 at 12:06 AM
>>>>>>>>>> To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Cc: "[e-mail]<mailto:drafts-lastcall-
>>>>>>>>>> [e-mail]>" <drafts-lastcall-
>>>>>>>>>> [e-mail]<mailto:drafts-
>>>>>>>>>> [e-mail]>>, Alvaro Retana
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Clarence
>>>>>>>>>> Filsfils (cfilsfil)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Peter Psenak (ppsenak)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, "Abhay Roy
>>>>>>>>>> (akr)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Stefano
>>>>>>>>>> Previdi <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Deborah
>>>>>>>>>> Brungard <[e-mail]<mailto:[e-mail]>>, Wim
>>>>>>>>>> Henderickx
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Subject: Re: [IANA #986195] Re: Last Call: <draft-ietf-ospf-
>>>>>>>>>> segment-
>>>>>>>>>> routing-extensions-19.txt> (OSPF Extensions for Segment
>>>>>>>>>> Routing) to
>>>>>>>>>> Proposed Standard
>>>>>>>>>>
>>>>>>>>>> Acee,
>>>>>>>>>>
>>>>>>>>>> Then is there a reason to not just pick one IGP's registry and
>>>>>>>>>> have
>>>>>>>>>> the other IGP's draft refer to it?
>>>>>>>>>> The field name can be explicit.
>>>>>>>>>>
>>>>>>>>>> I am concerned about creating different registry pages
>>>>>>>>>> eventually for
>>>>>>>>>> a number of different combos - and I'm
>>>>>>>>>> fairly resigned that many OSPF and IS-IS registries can
>>>>>>>>>> migrate into
>>>>>>>>>> use by BGP or BGP-LS...
>>>>>>>>>> For that matter, the OSPF draft used to refer to RSVP-TE
>>>>>>>>>> registries.
>>>>>>>>>>
>>>>>>>>>> As we already noted,  drafts can refer to existing registries
>>>>>>>>>> that
>>>>>>>>>> are
>>>>>>>>>> not associated with the WG. Since BGP-LS is used to encoding
>>>>>>>>>> information from many sources, I would fully expect that it
>>>>>>>>>> would
>>>>>>>>>> refer to registries from other protocols and believe this is
>>>>>>>>>> normal.
>>>>>>>>>> Also, while it is not common, a subsequent draft can rename a
>>>>>>>>>> registry
>>>>>>>>>> as part the IANA actions.
>>>>>>>>>>
>>>>>>>>>> If you are still concerned, we can go with a "Routing
>>>>>>>>>> Algorithms”
>>>>>>>>>> registry at the top level.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> What has happened with the same functionality defined by OSPF
>>>>>>>>>> and IS-
>>>>>>>>>> IS into registries in the past?
>>>>>>>>>> Do you recall?
>>>>>>>>>>
>>>>>>>>>> In the past, we’ve had separate protocol registries.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Acee
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alia
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 25, 2017 at 8:03 PM, Acee Lindem (acee)
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>>>>> Hi Alia,
>>>>>>>>>>
>>>>>>>>>> From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Date: Wednesday, October 25, 2017 at 3:47 PM
>>>>>>>>>> To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Cc: "[e-mail]<mailto:drafts-lastcall-
>>>>>>>>>> [e-mail]>" <drafts-lastcall-
>>>>>>>>>> [e-mail]<mailto:drafts-
>>>>>>>>>> [e-mail]>>, Alvaro Retana
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Clarence
>>>>>>>>>> Filsfils (cfilsfil)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Peter Psenak (ppsenak)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, "Abhay Roy
>>>>>>>>>> (akr)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Stefano
>>>>>>>>>> Previdi <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Deborah
>>>>>>>>>> Brungard <[e-mail]<mailto:[e-mail]>>, Wim
>>>>>>>>>> Henderickx
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Subject: Re: [IANA #986195] Re: Last Call: <draft-ietf-ospf-
>>>>>>>>>> segment-
>>>>>>>>>> routing-extensions-19.txt> (OSPF Extensions for Segment
>>>>>>>>>> Routing) to
>>>>>>>>>> Proposed Standard
>>>>>>>>>>
>>>>>>>>>> Hi Acee,
>>>>>>>>>>
>>>>>>>>>> I agree that too broad a category isn't good.  We already have
>>>>>>>>>> protocols using registry from other protocols and I haven't
>>>>>>>>>> seen
>>>>>>>>>> harm,
>>>>>>>>>> as long as it is clearly indicated.  The ospf-tunnel-
>>>>>>>>>> capabilities is
>>>>>>>>>> the one that I am thinking of. If we have Routing Protocol
>>>>>>>>>> Parameters
>>>>>>>>>> & different algorithms from MANET or ROLL came in, would that
>>>>>>>>>> be
>>>>>>>>>> acceptable?
>>>>>>>>>>
>>>>>>>>>> Yes. Although I doubt there will be much overlap between the
>>>>>>>>>> IGPs and
>>>>>>>>>> MANET or ROLL.
>>>>>>>>>>
>>>>>>>>>> I don't have a formed opinion on the most workable answer. I
>>>>>>>>>> would
>>>>>>>>>> like to better understand whether this is a general concern or
>>>>>>>>>> simply
>>>>>>>>>> relevant to the fact that the OSPF and IS-IS extensions to SR
>>>>>>>>>> add
>>>>>>>>>> what
>>>>>>>>>> can be a common registry.
>>>>>>>>>>
>>>>>>>>>> I believe the only requirement we have today is for IGP
>>>>>>>>>> algorithms.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Acee
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alia
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 25, 2017 at 3:07 PM, Acee Lindem (acee)
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>>>>> Hi Alia,
>>>>>>>>>>
>>>>>>>>>> If the registry category is too broad, it doesn’t help in
>>>>>>>>>> categorization of the registries. Hence, going to “Routing
>>>>>>>>>> Area
>>>>>>>>>> Parameters” wouldn’t be of much value. Since there aren’t that
>>>>>>>>>> many
>>>>>>>>>> routing protocols, we could go with “Routing Protocol
>>>>>>>>>> Parameters” as
>>>>>>>>>> the general category and “Routing Algorithms” as the new
>>>>>>>>>> registry. I
>>>>>>>>>> don’t see much commonality with BFD and SFC.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Acee
>>>>>>>>>>
>>>>>>>>>> From: Alia Atlas <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Date: Wednesday, October 25, 2017 at 10:16 AM
>>>>>>>>>> To: Acee Lindem <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Cc: "[e-mail]<mailto:drafts-lastcall-
>>>>>>>>>> [e-mail]>" <drafts-lastcall-
>>>>>>>>>> [e-mail]<mailto:drafts-
>>>>>>>>>> [e-mail]>>, Alvaro Retana
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Clarence
>>>>>>>>>> Filsfils (cfilsfil)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "Peter Psenak (ppsenak)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, "Abhay Roy
>>>>>>>>>> (akr)"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>, Jeff Tantsura
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Stefano
>>>>>>>>>> Previdi <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> Deborah
>>>>>>>>>> Brungard <[e-mail]<mailto:[e-mail]>>, Wim
>>>>>>>>>> Henderickx
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>,
>>>>>>>>>> "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>> Subject: Re: [IANA #986195] Re: Last Call: <draft-ietf-ospf-
>>>>>>>>>> segment-
>>>>>>>>>> routing-extensions-19.txt> (OSPF Extensions for Segment
>>>>>>>>>> Routing) to
>>>>>>>>>> Proposed Standard
>>>>>>>>>>
>>>>>>>>>> Hi Acee & Amanda,
>>>>>>>>>>
>>>>>>>>>> I think we need to have a bit of discussion on the proper
>>>>>>>>>> naming.
>>>>>>>>>> I do see a need for a more general registry - but I wonder
>>>>>>>>>> whether
>>>>>>>>>> there will not
>>>>>>>>>> be a case where BGP might need this registry.  I know that
>>>>>>>>>> BIER has
>>>>>>>>>> an
>>>>>>>>>> algorithm
>>>>>>>>>> field for future extensions and - while not intended for an
>>>>>>>>>> IANA
>>>>>>>>>> registry now - there
>>>>>>>>>> might be connections in the future.
>>>>>>>>>>
>>>>>>>>>> BIER and SFC both have next protocol fields, which are
>>>>>>>>>> currently
>>>>>>>>>> different - but if we
>>>>>>>>>> add a more general registry page, it should be able to
>>>>>>>>>> accommodate
>>>>>>>>>> this.
>>>>>>>>>>
>>>>>>>>>> I do see a need for common IGP registries as well going
>>>>>>>>>> forward.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alia
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, Oct 24, 2017 at 7:00 PM, Acee Lindem (acee)
>>>>>>>>>> <[e-mail]<mailto:[e-mail]>> wrote:
>>>>>>>>>> Hi Amanda,
>>>>>>>>>>
>>>>>>>>>> [Speaking as OSPF Co-Chair],
>>>>>>>>>>
>>>>>>>>>> What I think should be done is add a new category of registry
>>>>>>>>>> “IGP
>>>>>>>>>> Parameters” with “IGP Algorithms” being the first registry.
>>>>>>>>>> Sound
>>>>>>>>>> good
>>>>>>>>>> Everyone?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Acee
>>>>>>>>>>
>>>>>>>>>> On 10/24/17, 2:43 PM, "Amanda Baber via RT"
>>>>>>>>>> <[e-mail]<mailto:drafts-lastcall-
>>>>>>>>>> [e-mail]>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> This question is for the chairs as well.
>>>>>>>>>>>
>>>>>>>>>>> On Tue Oct 24 07:57:21 2017,
>>>>>>>>>>> [e-mail]<mailto:[e-mail]> wrote:
>>>>>>>>>>>> Hi Amanda,
>>>>>>>>>>>>
>>>>>>>>>>>> please see inline:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 24/10/17 00:28 , Amanda Baber via RT wrote:
>>>>>>>>>>>>> Hi Peter,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Should the new registry be placed at
>>>>>>>>>>>>> https://www.iana.org/assignments/ospf-parameters,
>>>>>>>>>>>>> https://www.iana.org/assignments/ospfv2-parameters, or
>>>>>>>>>>>>> elsewhere?
>>>>>>>>>>>>
>>>>>>>>>>>> given that this registry is shared between protocols, would
>>>>>>>>>>>> it be
>>>>>>>>>>>> possible to make it protocol independent?
>>>>>>>>>>>
>>>>>>>>>>> We can do this, but we'd like instructions from the chairs as
>>>>>>>>>>> well.
>>>>>>>>>>>
>>>>>>>>>>> If you look at the listings at http://www.iana.org/protocols,
>>>>>>>>>>> is
>>>>>>>>>>> there
>>>>>>>>>>> another existing web page would be appropriate? If not, what
>>>>>>>>>>> should
>>>>>>>>>>> be
>>>>>>>>>>> the title of the web page? Should it have a title that fits
>>>>>>>>>>> only the
>>>>>>>>>>> new
>>>>>>>>>>> registry, or should it accommodate additional related
>>>>>>>>>>> registries in
>>>>>>>>>>> the
>>>>>>>>>>> future? Can a chair confirm that it should be placed at a new
>>>>>>>>>>> page
>>>>>>>>>>> and
>>>>>>>>>>> not an existing one?
>>>>>>>>>>>
>>>>>>>>>>>>> Does this registry have three fields (Value, Description,
>>>>>>>>>>>>> Reference)
>>>>>>>>>>>>> or four (Value, Name -- consisting of the first sentence in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> description?, Description, Reference)?
>>>>>>>>>>>>
>>>>>>>>>>>> 3 values - Value, Name, Reference
>>>>>>>>>>>>
>>>>>>>>>>>> I'm going to change the name from "SR-Algorithm Registry" to
>>>>>>>>>>>> "IGP
>>>>>>>>>>>> Algorithm Registry" based on the comments I got and possible
>>>>>>>>>>>> future
>>>>>>>>>>>> usage outside of SR.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks,
>>>>>>>>>>>> Peter
>>>>>>>>>>>
>>>>>>>>>>> thanks,
>>>>>>>>>>> Amanda
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri Oct 20 09:11:19 2017,
>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]> wrote:
>>>>>>>>>>>>>> Hi Sabrina,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I posted a new version - draft-ietf-ospf-segment-routing-
>>>>>>>>>>>>>> extensions-
>>>>>>>>>>>>>> 20.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have fixed the code points as mentioned previously.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This version also defines additional new registry - "SR-
>>>>>>>>>>>>>> Algorithm
>>>>>>>>>>>>>> Registry" in section 8.5. This is a common registry that
>>>>>>>>>>>>>> will be
>>>>>>>>>>>>>> shared
>>>>>>>>>>>>>> by OSPF and ISIS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>> Peter
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Sabrina,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 16/10/17 13:51 , Acee Lindem (acee) wrote:
>>>>>>>>>>>>>>>> Hi Sabrina,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> See inline.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 10/12/17, 1:59 PM, "Sabrina Tanamal via RT" <drafts-
>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (BEGIN IANA COMMENTS)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IESG/Authors/WG Chairs:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The IANA Services Operator has completed its review of
>>>>>>>>>>>>>>>>> draft-ietf-ospf-segment-routing-extensions-19. If any
>>>>>>>>>>>>>>>>> part of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> review
>>>>>>>>>>>>>>>>> is inaccurate, please let us know.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The IANA Services Operator has a question about one of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> actions
>>>>>>>>>>>>>>>>> requested in the IANA Considerations section of this
>>>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The IANA Services Operator understands that, upon
>>>>>>>>>>>>>>>>> approval of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> document, there are four actions which we must
>>>>>>>>>>>>>>>>> complete.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> First, in the OSPF Router Information (RI) TLVs
>>>>>>>>>>>>>>>>> registry on
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> Open
>>>>>>>>>>>>>>>>> Shortest Path First (OSPF) Parameters registry page
>>>>>>>>>>>>>>>>> located at
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ospf-parameters/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The temporary registration for value 8, SR-Algorithm
>>>>>>>>>>>>>>>>> TLV, will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>> permanent and its reference changed to [ RFC-to-be ].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The temporary registration for value 9, SID/Label Range
>>>>>>>>>>>>>>>>> TLV,
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> made
>>>>>>>>>>>>>>>>> permanent and its reference changed to [ RFC-to-be ].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IANA Question --> is any action to be taken with the
>>>>>>>>>>>>>>>>> temporary
>>>>>>>>>>>>>>>>> registration for value 12, Node MSD TLV?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Not right now - MSD is standardized in another draft.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Two additional registrations are to be made as follows
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Value: [ TBD-at-registration ]
>>>>>>>>>>>>>>>>> TLV Name: SR Local Block TLV
>>>>>>>>>>>>>>>>> Reference: [ RFC-to-be ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Value: [ TBD-at-registration ]
>>>>>>>>>>>>>>>>> TLV Name: SRMS Preference TLV
>>>>>>>>>>>>>>>>> Reference: [ RFC-to-be ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We note that the authors suggest values 12 and 13 for
>>>>>>>>>>>>>>>>> these
>>>>>>>>>>>>>>>>> two
>>>>>>>>>>>>>>>>> registrations, however 12 is already allocated via a
>>>>>>>>>>>>>>>>> temporary
>>>>>>>>>>>>>>>>> registration (see above).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These TLVs can take the next unassigned values.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I would suggest to keep 13 for SRMS Preference TLV and
>>>>>>>>>>>>>>> allocate
>>>>>>>>>>>>>>> 14
>>>>>>>>>>>>>>> to SR
>>>>>>>>>>>>>>> Local Block TLV. I'll fix the draft-ietf-ospf-segment-
>>>>>>>>>>>>>>> routing-
>>>>>>>>>>>>>>> extensions
>>>>>>>>>>>>>>> accordingly.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks,
>>>>>>>>>>>>>>> Peter
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Second,in theOSPFv2 Extended Prefix Opaque LSA TLVs
>>>>>>>>>>>>>>>>> registry
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> the Open
>>>>>>>>>>>>>>>>> Shortest Path First v2 (OSPFv2) Parameters registry
>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>> located
>>>>>>>>>>>>>>>>> at:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ospfv2-parameters/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the temporary registration for value 2, OSPF Extended
>>>>>>>>>>>>>>>>> Prefix
>>>>>>>>>>>>>>>>> Range TLV,
>>>>>>>>>>>>>>>>> will be made permanent and its reference will be
>>>>>>>>>>>>>>>>> changed to [
>>>>>>>>>>>>>>>>> RFC-to-be ].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Third, in the OSPFv2 Extended Prefix TLV Sub-TLVs also
>>>>>>>>>>>>>>>>> on the
>>>>>>>>>>>>>>>>> Open
>>>>>>>>>>>>>>>>> Shortest Path First v2 (OSPFv2) Parameters registry
>>>>>>>>>>>>>>>>> page
>>>>>>>>>>>>>>>>> located
>>>>>>>>>>>>>>>>> at:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ospfv2-parameters/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The temporary registration for value 1, SID/Label Sub-
>>>>>>>>>>>>>>>>> TLV,
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be made
>>>>>>>>>>>>>>>>> permanent and its reference will be changed to [ RFC-
>>>>>>>>>>>>>>>>> to-be ].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The temporary registration for value 2, Prefix SID Sub-
>>>>>>>>>>>>>>>>> TLV,
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be made
>>>>>>>>>>>>>>>>> permanent and its reference will be changed to [ RFC-
>>>>>>>>>>>>>>>>> to-be ].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> IANA Question --> is any action to be taken for the
>>>>>>>>>>>>>>>>> temporary
>>>>>>>>>>>>>>>>> registrations for values 3, 4, 5, 6, 7 adn 8 in this
>>>>>>>>>>>>>>>>> registry?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> These have been removed from the draft and the values
>>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>>> returned to
>>>>>>>>>>>>>>>> unassigned state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Fourth, in the OSPFv2 Extended Link TLV Sub-TLVs
>>>>>>>>>>>>>>>>> registry also
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> Open Shortest Path First v2 (OSPFv2) Parameters
>>>>>>>>>>>>>>>>> registry page
>>>>>>>>>>>>>>>>> located
>>>>>>>>>>>>>>>>> at:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://www.iana.org/assignments/ospfv2-parameters/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> the following temporary registrations will be made
>>>>>>>>>>>>>>>>> permanent
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> their
>>>>>>>>>>>>>>>>> references changed to [ RFC-to-be ] as follows:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Value: 1
>>>>>>>>>>>>>>>>> Description: SID/Label Sub-TLV
>>>>>>>>>>>>>>>>> Reference: [ RFC-to-be ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Value: 2
>>>>>>>>>>>>>>>>> Description: Adj-SID Sub-TLV
>>>>>>>>>>>>>>>>> Reference: [ RFC-to-be ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Value: 3
>>>>>>>>>>>>>>>>> Description: LAN Adj-SID/Label Sub-TLV
>>>>>>>>>>>>>>>>> Reference: [ RFC-to-be ]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The IANA Services Operator understands that these four
>>>>>>>>>>>>>>>>> actions
>>>>>>>>>>>>>>>>> are the
>>>>>>>>>>>>>>>>> only ones required to be completed upon approval of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> document.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Acee
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note:  The actions requested in this document will not
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> completed
>>>>>>>>>>>>>>>>> until
>>>>>>>>>>>>>>>>> the document has been approved for publication as an
>>>>>>>>>>>>>>>>> RFC. This
>>>>>>>>>>>>>>>>> message is
>>>>>>>>>>>>>>>>> only to confirm what actions will be performed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thank you,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sabrina Tanamal
>>>>>>>>>>>>>>>>> IANA Services Specialist
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (END IANA COMMENTS)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> .
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> .
>>>
>
>
>
> .
>