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

tom petch <daedulus@xxxxxxxxxxxxx> · Mon, 30 Nov 2020 10:47:04 +0000

On 27/11/2020 14:35, Acee Lindem (acee) wrote:
Hi Tom
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

Thanks,
Acee

On 11/26/20, 5:43 AM, "tom petch" <daedulus@xxxxxxxxxxxxx> wrote:

 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" <daedulus@xxxxxxxxxxxxx> 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

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call