Re: [spring] [Idr] draft-ietf-spring-segment-routing-policy

[tom petch <[e-mail]>]

Ketan

IANA will register anything if you ask them nicely; look for example at
YANG modules or namespaces:-)

You need a policy - how entries are to be added or amended - a format,
initial entries and a sensible name or set of names. RFC8126 is helpful.

Do not expect IANA to have any technical skills in the technology, IDR,
SPRING, TCP etc.  It is nice when they do but the instructions to them
should assume none.

Tom Petch


----- Original Message -----
From: "Ketan Talaulikar (ketant)" <[e-mail]>
To: <[e-mail]>
Cc: "SPRING WG List" <[e-mail]>
Sent: Friday, October 18, 2019 4:05 PM


> < BCC – IDR alias since the drafts under discussions are Spring
documents >
>
> Hi Bruno,
>
> Is it possible to check if we can create an IANA registry and use for
the purpose for referencing segment types? I may be wrong about IANA
managing only protocol codepoints.
>
> Thanks,
> Ketan
>
> From: [e-mail] <[e-mail]>
> Sent: 18 October 2019 20:10
> To: Ketan Talaulikar (ketant) <[e-mail]>
> Cc: idr wg <[e-mail]>; SPRING WG List <[e-mail]>
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Ketan
>
> From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
> Sent: Thursday, October 17, 2019 7:49 PM
> To: DECRAENE Bruno TGI/OLN
> Cc: idr wg; SPRING WG List
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Bruno,
>
> I now understand your point with the two draft references you have
provided. I do believe we need to ensure that the “Types” in [1] are
managed in a way that future values are kept consistent across
drafts/areas.
>
> It might be too late for the codepoints in
draft-ietf-idr-segment-routing-te-policy since we have implementations
and deployments, but we can ensure for everything else.
>
> Would you suggest we get create a registry with IANA for this via
draft-ietf-spring-segment-routing-policy? Or is there some other way?
> [Bruno] I’m not aware of other ways. I was suggesting to create an
IANA registry, but your comment that this is restricted for protocol
code points make me doubt.
>                There is also the option of removing the Type numbers
if you think that they are not that useful. That would remove the
problem. Possibly with using shorter names for them (e.g, MPLS label,
IPv6 SID, …)
>
> At this point, the subject looks restricted to SPRING, so possibly we
could stop copying IDR.
>
> Thanks,
> --Bruno
>
> Thanks,
> Ketan
>
> From: [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>
> Sent: 17 October 2019 20:24
> To: Ketan Talaulikar (ketant)
<[e-mail]<mailto:[e-mail]>>
> Cc: idr wg <[e-mail]<mailto:[e-mail]>>; SPRING WG List
<[e-mail]<mailto:[e-mail]>>
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Ketan,
>
> My point was not related to the alignment of code points but to the
fact that there is no provision taken to guarantee that in the future
“Types” defined in [1] be unique/(a unique idenfitier).
> This type may eventually be used in protocol, e.g. yang model [2], in
which case collision would be an issue.
>
> But if a collision of such SID types, as defined in [1], is acceptable
for you, let it be. In which case, possibly [2] should use the names
rather than the number (e.g. “SR-MPLS Label” rather than
 “segment-type-1”)
>
> [1]
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-03#
section-4
> [2]
https://tools.ietf.org/html/draft-raza-spring-sr-policy-yang-01#section-
4.2.1
>
>
> --Bruno
>
>
>
>
> From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
> Sent: Thursday, October 17, 2019 8:27 AM
> To: DECRAENE Bruno TGI/OLN
> Cc: idr wg; SPRING WG List
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Bruno,
>
> A codepoint is a number that is allocated by IANA and sent over the
wire as part of a protocol encoding. It is protocol/registry specific.
E.g. we can have the same Segment Type signalled by codepoint “9” in
https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-12#sectio
n-9.7 while it is signalled by codepoint “10” in
https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#
section-8.4 – there is no issue functionally. It would be nice to have
those aligned across the two since they have semantic similarity but it
is not necessary.
>
> A reference is just that – a short form instead of using a long
descriptive name. So a segment of “Type 9” that is referred in
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-03#
section-4 is what is signalled using codepoint 9 in BGP-LS while using
codepoint 10 for SRTE. You will see places in the
draft-ietf-spring-segment-routing-policy where these “types” are
referred to – e.g.
https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-03#
section-5.1.
>
> Ideally, it would have been great to have the reference and codepoints
(across registries) aligned – but it is not necessary.
>
> In summary, besides the correction needed in
draft-ietf-idr-segment-routing-te-policy in section 2.4.3.2 (and it’s
sub-sections) as described in my email below, I do not see any issue
here.
>
> If you think we need some text changes to improve this clarity in any
draft, please do suggest.
>
> Thanks,
> Ketan
>
> From: [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>
> Sent: 15 October 2019 14:46
> To: Ketan Talaulikar (ketant)
<[e-mail]<mailto:[e-mail]>>
> Cc: idr wg <[e-mail]<mailto:[e-mail]>>; SPRING WG List
<[e-mail]<mailto:[e-mail]>>
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Keta,
>
> Please check inline [Bruno2]
>
> From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
> Sent: Tuesday, October 15, 2019 6:56 AM
> To: DECRAENE Bruno TGI/OLN; SPRING WG List
> Cc: idr wg
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Bruno,
>
> Please check inline below.
>
> From: [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>
> Sent: 23 September 2019 22:08
> To: Ketan Talaulikar (ketant)
<[e-mail]<mailto:[e-mail]>>; SPRING WG List
<[e-mail]<mailto:[e-mail]>>
> Cc: idr wg <[e-mail]<mailto:[e-mail]>>
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> Hi Ketan,
>
> Thanks for the complete answer. And sorry for my delay in responding.
> More inline [Bruno]
>
> From: Ketan Talaulikar (ketant) [mailto:[e-mail]]
> Sent: Friday, August 2, 2019 4:37 AM
> To: DECRAENE Bruno TGI/OLN; SPRING WG List
> Cc: idr wg
> Subject: RE: draft-ietf-spring-segment-routing-policy
>
> + IDR WG since some of the affected documents are IDR WG drafts
>
> Hi Bruno,
>
> I agree that the draft-ietf-spring-segment-routing-policy [1] is the
right place to normatively define the different segment types and
perhaps would have been the right document to create an IANA registry
for them.
>
> I also agree that the draft-ietf-idr-segment-routing-te-policy [2] has
a discrepancy between its IANA section 8.4 for the Segment-List sub-TLV
space and section 2.4.3.2 (and it’s sub-sections) where the different
Segment Types have been defined. I will request the authors of this
draft to fix the text in section 2.4.3.2 (and it’s sub-sections) for the
types 8 and above to adjust for the codepoint 9 allocated for the weight
sub-TLV.
>
> At this point, given the implementations available and already
deployed for [2], I doubt if we can correct and map the segment types in
that draft to what has been defined in [1].
>
> There is also the
https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-11#sectio
n-9.7 which creates the Segment Types IANA registry (aligned with [1]).
>
> [Bruno] This IANA registry seems BGP-LS specific. (sub-registry under
"Border Gateway Protocol - Link State (BGP-LS) Parameters")
> On a side note,
>
> >  “The registry contains the following codepoints (suggested values,
to be assigned by IANA)”
> Since you define a new registry, you can populate initial allocations
at your own will. IOW :s/(suggested values, to be assigned by IANA)”/
> [KT] Thanks. Fixed it in the version just posted.
>
>
>
> And then I am not sure if draft-raza-spring-sr-policy-yang is able to
benefit/leverage the IANA registry from [1].
>
> So unless we can have the IANA registry created via [1] being
consistently used in all dependent documents, I do not see much gain in
setting up the Segment Type registry under IANA at this point.
> [Bruno] Make sense, but brings three clarification questions:
> Is there a need for draft-ietf-spring-segment-routing-policy to define
numbers for the segment types (or is the name enough)?
> [KT] The names are long and descriptive (as you can see) and hence the
numbers allow for easy reference through the rest of the document.
> [Bruno2] I’m fine with a number. But if the numbers are to be used as
a useful reference, it looks like a number must only reference one type
of segment.
>
> IOW, if someone reference: Type 2: SRv6 SID: while someone else use
the same number for a different reference: Type 2: SR-MPLS Label. then
Type 2 doesn’t seem like a useful reference anymore.
>
>   If yes, do we need such numbers of be unique (avoid collisions)?
> [KT] The numbers in draft-ietf-spring-segment-routing-policy are not
code-points today and just reference numbers. So there is no concept of
collision with the code-points defined in other registries? Would it
help if draft-ietf-spring-segment-routing-policy were to refer to
segment types as A,B,C so as to avoid this confusion? 😊
> [Bruno2] no, that would not help in any way.
> I’m not sure what the difference you make between a code point and a
reference. Is the former to be used by computer and the latter by
humans? If so, don’t you think that human also deserve unambiguous
reference?
>
>      If yes, how do you propose to avoid code point collisions in the
future? (Or do you assume that there won’t be future ones?)
> [KT] I would not rule out future segment types.
>
>  [Bruno2] That seem to answer the second question in brackets, but not
the main one.
>
> Let’s take an example: would you be fine with a document defining Type
2: SRv6+ SID: ?
>
>         If so, what’s the purpose of a reference (type 2) which does
not uniquely identify something?
>
> If not, how do you propose to avoid collision between reference
numbers?
>
>
>
> Taking another example, lets reference “coffee” as type 2 and “tea” as
type 2. Could you please bring me a cup of type 2?
>
>
>
> Thanks,
>
> --Bruno
>
>
>
>
>
>
> Thanks,
> Ketan
>
> Thanks,
> Bruno
>
>
>
>
> Thanks,
> Ketan
>
> From: spring <[e-mail]<mailto:[e-mail]>>
On Behalf Of [e-mail]<mailto:[e-mail]>
> Sent: 01 August 2019 19:10
> To: SPRING WG List <[e-mail]<mailto:[e-mail]>>
> Subject: [spring] draft-ietf-spring-segment-routing-policy
>
> Hi authors,
>
> Speaking as individual contributor.
>
> This document seems to define multiple types of segments (1 to 11).
> May be this document would be the right place to define them
normatively and creates the IANA registry for them. And this seems like
a work for spring.
> Otherwise, there is a risk that other documents redefine them,
possibly in a non-consistent manner. (1) E.g.  the BGP draft is not
using the same type numbers/name, which may bring confusion. I would
expect YANG models to also need these types.
> BTW is there any chance to align the types in the BGP document or is
this too late? (alternatively may be changing the types in the sr-policy
document)
>
> Thanks,
> Regards,
> Bruno
>
> (1)
> SR-policy:
>
>    Type 1: SR-MPLS Label:
>
>    Type 2: SRv6 SID:
>
>    Type 3: IPv4 Prefix with optional SR Algorithm:
>
>    Type 4: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
>
>    Type 5: IPv4 Prefix with Local Interface ID:
>
>    Type 6: IPv4 Addresses for link endpoints as Local, Remote pair:
>
>    Type 7: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS:
>
>    Type 8: IPv6 Addresses for link endpoints as Local, Remote pair for
SR-MPLS:
>
>    Type 9: IPv6 Global Prefix with optional SR Algorithm for SRv6:
>
>    Type 10: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6:
>
>    Type 11: IPv6 Addresses for link endpoints as Local, Remote pair
for SRv6:
>
>
> BGP:
>    1     MPLS SID sub-TLV                            This document
>    2     SRv6 SID sub-TLV                            This document
>    3     IPv4 Node and SID sub-TLV                   This document
>    4     IPv6 Node and SID for SR-MPLS sub-TLV       This document
>    5     IPv4 Node, index and SID sub-TLV            This document
>    6     IPv4 Local/Remote addresses and SID sub-TLV This document
>    7     IPv6 Node, index for remote and local pair  This document
>          and SID for SR-MPLS sub-TLV
>    8     IPv6 Local/Remote addresses and SID sub-TLV This document
>    9     Weight sub-TLV                              This document
>    10    IPv6 Node and SID for SRv6 sub-TLV          This document
>    11    IPv6 Node, index for remote and local pair  This document
>          and SID for SRv6 sub-TLV
>    12    IPv6 Local/Remote addresses and SID for     This document
>          SRv6 sub-TLV
>
>
>
________________________________________________________________________
_________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
>
> Thank you.
>
>
________________________________________________________________________
_________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
>
> Thank you.
>
>
________________________________________________________________________
_________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
>
> Thank you.
>
>
________________________________________________________________________
_________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
>
> Thank you.
>
>
________________________________________________________________________
_________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or
privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and
delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
>
> Thank you.
>


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


> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>