Subject: Re: [Last-Call] Last Call: <draft-ietf-spring-sr-yang-23.txt> (YANG Data Model for Segment Routing) to Proposed Standard

From: tom petch <[email-masked]>
Date: Wed, 18 Nov 2020 12:39:19 +0000

IANA Considerations does not register the module names used in the modules

Examples are IPv4 only, IPv6 would be good

BGP is included when it comes to defining a router-id but is ignored 
everywhere else, such as signalling MSD, protocol extensions etc

reference "RFC XXXX" would be improved by including the title in all 
cases not just some

the scheme http: appears in many places.  It would be lovely if this 
really was the scheme but I fear that it is not

module srcmn
  the upper bound must be larger
  the value must be greater
consistency is good - I think greater is better

8.3
operation states
usually operational

two imports lack references

typedef router-id
this is a well known type from RFC8394; it seems likely to confuse to 
redefine it with a related but different meaning

leaf enabled
enables protocol extensions
which protocols?

leaf protected
it is used to protect
how does it do that:-)

enum dual
... In this case will be advertised with backup flag set
What is the backup flag?  It does not feature in RFC8660.  Needs an 
explanation and reference

container link-msd
  list link-msds
    leaf msd
The usual YANG convention is for a list to be plural and the leaf 
singular.  You have the plural list but not the leaf.  And who needs the 
container?  This is mpls not a common module that might be augmented so 
what does the container give apart from complexity?

list policy
  leaf string
YANG string caters for very large items of very complex character sets. 
  Is that desirable?

leaf used
will used plus free equal size?

Indicates if the binding is /instal/installed/

notification-segment-routing-global-srgb-collision
a mix of conflict and collision;  consistency is good and I prefer the 
latter which is the name of the notification

containing /s/a/ mapping

... sid collision
again consistency good, prefer collision to conflicting

s.9
I would have thought the srgb worthy of mention under sensitive nodes

Tom Petch

On 16/11/2020 19:32, The IESG wrote:
>
> The IESG has received a request from the Source Packet Routing in Networking
> WG (spring) to consider the following document: - 'YANG Data Model for
> Segment Routing'
>    <draft-ietf-spring-sr-yang-23.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-11-30. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document defines a YANG data model for segment routing
>     configuration and operation, which is to be augmented by different
>     segment routing data planes.  The document also defines a YANG model
>     that is intended to be used on network elements to configure or
>     operate segment routing MPLS data plane, as well as some generic
>     containers to be reused by IGP protocol modules to support segment
>     routing.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 23 Nov 2020 17:27:40 +0000

Hi Tom, 

See a couple responses inline enclosed in <acee> and </acee>. We are addressing the rest of your comments. 

On 11/18/20, 7:39 AM, "tom petch" <[email-masked]> wrote:

<acee>
This is in the IANA considerations... 

   This document registers a YANG module in the YANG Module Names
   registry [RFC6020].

      name: ietf-segment-routing-common
      namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-common
      prefix: sr-cmn
      reference: RFC XXXX

      name: ietf-segment-routing
      namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing
      prefix: sr
      reference: RFC XXXX

      name: ietf-segment-routing
      namespace: urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls
      prefix: sr-mpls
      reference: RFC XXXX
</acee>

    the scheme http: appears in many places.  It would be lovely if this 
    really was the scheme but I fear that it is not
<acee>
This is directly from the RFC 8407 template in Appendix B. What would you suggest? 
</acee>

    module srcmn

    8.3
    operation states
    usually operational

    typedef router-id

    leaf enabled

    leaf protected
    it is used to protect
    how does it do that:-)

    enum dual

    container link-msd
      list link-msds
        leaf msd
    The usual YANG convention is for a list to be plural and the leaf 
    singular.  You have the plural list but not the leaf. 
<acee> 
So you are asking for a change from "leaf msd" to "leaf link-msd"? 
</acee>

 And who needs the 

    list policy
      leaf string
    YANG string caters for very large items of very complex character sets. 
      Is that desirable?
<acee>
IETF models normally do not limit identifiers. An individual implementation could do this with a deviation. 
</acee> 

Thanks,
Acee

    leaf used

    containing /s/a/ mapping

    ... sid collision

    s.9

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Tue, 24 Nov 2020 09:34:10 +0000

> This is in the IANA considerations...

<tp>
Indeed; I do not see a registration of ietf-segment-routing-mpls!

> This is directly from the RFC 8407 template in Appendix B. What would you suggest?

<tp>
Many I-D do now specify https: since that is now the only option 
supported by the IETF; I have seen this called for by an AD.

> So you are asking for a change from "leaf msd" to "leaf link-msd"?

<tp>
Yes I would especially given node-msd.  I wish that YANG Guidelines said 
more about container names.  I think that having the same identifier for 
container, for list, for leaf (which I have seen in another I-D)
will lead to mistakes so having a convention for list and leaf will 
reduce mistakes but having another for container would be even better. 
That said, I have yet to think of a good convention
In passing, must link-msd be >= node-msd?

> IETF models normally do not limit identifiers. An individual implementation could do this with a deviation.

<tp>
I know - I did see an AD challenge that, I think in IESG review, not 
long ago.  SMI was better at this!

Tom Petch

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 24 Nov 2020 14:48:36 +0000

Hi Tom, 

On 11/24/20, 4:34 AM, "tom petch" <[email-masked]> wrote:

    <tp>

Yes - I see the typo now that you pointed out which one. 

    <tp>

As long as the URLs work, I don't see a problem with either. 

    <tp>
Like you said, this would be the third time for link-msd(s). I'll see what my co-authors think. 

    In passing, must link-msd be >= node-msd?
Yes - this is clear in the associated MSD protocol drafts. 

    <tp>

Since we have standardized on a maximum length for identifiers or even policy identifiers, I'm not going to pick one specific to this draft. It goes without saying that implementations will have a limit. 

Thanks,
Acee

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 26 Nov 2020 10:42:58 +0000

I have looked at -26 and it looks good apart from BGP.

BGP gets a mention in passing but does not get the same treatment as the 
protocols of the LSR WG.  I am unclear whether or not this I-D is 
intended to include networks using BGP or not with e.g. signalling of 
MSD and would value a clarification in the I-D.

I wonder about the final D in
Maximum SID Depth (MSD)D
in the YANG; I suspect that it is spurious.

Tom Petch

On 24/11/2020 09:34, tom petch wrote:
>> IETF models normally do not limit identifiers. An individual
>> implementation could do this with a deviation.
>
> <tp>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 26 Nov 2020 10:54:46 -0800

> supported by the IETF; I have seen this called for by an AD.

I think we have typically been using https: in recent RFCs, but we should
probably write a (very short) draft to update 8407 and the template
therein.

Any volunteers?

-Ben

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 27 Nov 2020 14:35:58 +0000

Hi Tom 
Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:". 
Thanks,
Acee

On 11/26/20, 5:43 AM, "tom petch" <[email-masked]> wrote:

    Tom Petch

---

From: tom petch <[email-masked]>
Date: Mon, 30 Nov 2020 10:47:04 +0000

> Please see the -27 version. I believe it addresses your concerns as well as changing "http:" to "https:".

Acee
I was too slow to see -27 but have looked at -28:-)  Yes I like the 
references to BGP.  I do sense a reluctance to reference I-D from other 
WG with the potential delays that can cause so that e.g. 'weight' could 
reference an IDR I-D alongside the LSR ones but I am not too fussed 
about that.  I do see a 'deptt' that might be 'depth' in a BGP reference 
to RFC 8814.
I think that s.3 needs updating.  I have done my homework and see the 
split in the YANG modules that came in with -15.  I think that s.3 
describes the old segment-routing when it had some data in it which it 
no longer has.  The description clause in segment-routing also probably 
overstates the case for what it now is, just an anchor waiting to be 
augmented.
I note that Table 1 omits the prefix defined in this I-D which I can 
live with.

Tom Petch