Hi Alia,
From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Thursday, October 26, 2017 at 12:06 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "drafts-lastcall-comm...@iana.org<mailto:drafts-lastcall-
comm...@iana.org>" <drafts-lastcall-
comm...@iana.org<mailto:drafts-
lastcall-comm...@iana.org>>, Alvaro Retana
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>,
"Clarence
Filsfils (cfilsfil)"
<cfils...@cisco.com<mailto:cfils...@cisco.com>>,
"Peter Psenak (ppsenak)"
<ppse...@cisco.com<mailto:ppse...@cisco.com>>, "Abhay Roy
(akr)"
<a...@cisco.com<mailto:a...@cisco.com>>,
"han...@rtbrick.com<mailto:han...@rtbrick.com>"
<han...@rtbrick.com<mailto:han...@rtbrick.com>>, Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>,
Stefano
Previdi <stef...@previdi.net<mailto:stef...@previdi.net>>,
Deborah
Brungard <db3...@att.com<mailto:db3...@att.com>>, Wim
Henderickx
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>,
"ro...@google.com<mailto:ro...@google.com>"
<ro...@google.com<mailto:ro...@google.com>>
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)
<a...@cisco.com<mailto:a...@cisco.com>> wrote:
Hi Alia,
From: Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Wednesday, October 25, 2017 at 3:47 PM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "drafts-lastcall-comm...@iana.org<mailto:drafts-lastcall-
comm...@iana.org>" <drafts-lastcall-
comm...@iana.org<mailto:drafts-
lastcall-comm...@iana.org>>, Alvaro Retana
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>,
"Clarence
Filsfils (cfilsfil)"
<cfils...@cisco.com<mailto:cfils...@cisco.com>>,
"Peter Psenak (ppsenak)"
<ppse...@cisco.com<mailto:ppse...@cisco.com>>, "Abhay Roy
(akr)"
<a...@cisco.com<mailto:a...@cisco.com>>,
"han...@rtbrick.com<mailto:han...@rtbrick.com>"
<han...@rtbrick.com<mailto:han...@rtbrick.com>>, Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>,
Stefano
Previdi <stef...@previdi.net<mailto:stef...@previdi.net>>,
Deborah
Brungard <db3...@att.com<mailto:db3...@att.com>>, Wim
Henderickx
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>,
"ro...@google.com<mailto:ro...@google.com>"
<ro...@google.com<mailto:ro...@google.com>>
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)
<a...@cisco.com<mailto:a...@cisco.com>> 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 <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Wednesday, October 25, 2017 at 10:16 AM
To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>
Cc: "drafts-lastcall-comm...@iana.org<mailto:drafts-lastcall-
comm...@iana.org>" <drafts-lastcall-
comm...@iana.org<mailto:drafts-
lastcall-comm...@iana.org>>, Alvaro Retana
<aretana.i...@gmail.com<mailto:aretana.i...@gmail.com>>,
"Clarence
Filsfils (cfilsfil)"
<cfils...@cisco.com<mailto:cfils...@cisco.com>>,
"Peter Psenak (ppsenak)"
<ppse...@cisco.com<mailto:ppse...@cisco.com>>, "Abhay Roy
(akr)"
<a...@cisco.com<mailto:a...@cisco.com>>,
"han...@rtbrick.com<mailto:han...@rtbrick.com>"
<han...@rtbrick.com<mailto:han...@rtbrick.com>>, Jeff Tantsura
<jefftant.i...@gmail.com<mailto:jefftant.i...@gmail.com>>,
Stefano
Previdi <stef...@previdi.net<mailto:stef...@previdi.net>>,
Deborah
Brungard <db3...@att.com<mailto:db3...@att.com>>, Wim
Henderickx
<wim.henderi...@nokia.com<mailto:wim.henderi...@nokia.com>>,
"ro...@google.com<mailto:ro...@google.com>"
<ro...@google.com<mailto:ro...@google.com>>
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)
<a...@cisco.com<mailto:a...@cisco.com>> 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"
<drafts-lastcall-comm...@iana.org<mailto:drafts-lastcall-
comm...@iana.org>> wrote:
Hi,
This question is for the chairs as well.
On Tue Oct 24 07:57:21 2017,
ppse...@cisco.com<mailto:ppse...@cisco.com> 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,
ppse...@cisco.com<mailto:ppse...@cisco.com> 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-
lastc...@iana.org<mailto:lastc...@iana.org>>
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)
.
