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

[tom petch <[e-mail]>]

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:
> On 23/11/2020 17:27, Acee Lindem (acee) wrote:
>> 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" <[e-mail]> wrote:
>>
>>      IANA Considerations does not register the module names used in
>> the modules
>>
>> <acee>
>> This is in the IANA considerations...
>
> <tp>
> Indeed; I do not see a registration of ietf-segment-routing-mpls!
>
>>     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>
>>
>>      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
>> <acee>
>> 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.
>
>
>> </acee>
>>
>>      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.
>> <acee>
>> 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?
>
>> </acee>
>>
>>
>>   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?
>> <acee>
>> 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
>
>> </acee>
>>
>> Thanks,
>> Acee
>>
>>      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