Re: [mpls] New Version Notification for draft-qu-mpls-mpls-msd-yang-01.txt

From: Yingzhen Qu <yingzhen.ietf@gmail.com>
Sent: 02 August 2021 23:44

Hi Tom,

Thank you for your review and comments. I have submitted version -02 to address your comments. Please see my detailed answers below.

<tp>

I was looking at draft-ietf-teas-yang-sr-topo and realised how much that had in common with this I-D, down to the same spelling mistakes!  To the TEAS WG list I posted

========================================
Both I-D puzzle me in the same way.  What is node-msd that it is a list keyed on msd-type?  And what is msd-type for that matter, same in both I-D?

 I understand a node having an MSD, the lowest of those on a link but how can that be a list and why key it on msd-type which appears to be the signalling protocol in use?  I do not understand.

 I note that in -08 node-msd was not a list and that made more sense to me.

 If a list is needed, then I think that you need to say why, how it is used - or reference another SR I-D/RFC where it is explained - and why it is keyed on what it is keyed on.

Equally fundamentally, what has node-msd got to do with te or topo or MPLS or ...  I see it as a property of a node which would ideally be part of a base definition of a node even if SR was not in use or part of a base SR augmentation as opposed to what we seem to be getting of  multiple I-D creating their own definitions of node-msd.
===============end of quote=========================

So is this the right I-D to define node-msd?  Probably not.

Why is node-msd a list and not a single object for a single node?

You queried my reference to BGP-LS.  There are three protocols which support SR, three protocols which can signal MSD, BGP-LS is one of them; all three appear in draft-ietf-teas-yang-sr-topo so why not here?

The editorial changes look good to me.

Tom Petch

 Thanks,
 - Xufeng

 _______________________________________________

Thanks,
Yingzhen
>  *   updated security consideration with detailed node info
>  *   minor editorial changes
>
> The draft was originally part of the Segment Routing model, now RFC 9020. It was suggested during AD review to split the MSD part off the SR model since it's a generic MPLS parameter. The model is small and straightforward, and had been literally reviewed many times while it was part of the SR model. We'd like the MPLS WG review it, and request WG adoption.
>
> If you have any comments, please let us know.
>
> <tp>
> I started off with some YANG quirks but ended up concluding I really do not understand the purpose of this I-D.
>
> You create a list indexed by interface-ref for MSD.  MPLS YANG already has a list of interfaces.  Why not use it?
[Yingzhen]: Good suggestion. I’ve made the change.
>
> You create a list for nodes indexed by msd-type.  Why? and what is the point of  msd-type?
>
> More generally I do not understand what the identity are doing.  You have no identity for two of the three signalling protocols.  I do not know what the purpose of msd-type is.  Needs justifying in the body of the I-D IMO.
[Yingzhen]: the identity of msd-type is for future extension. In case there are new types created later.
>
> You specify two protocols for signalling MSD; why not BGP-LS?
[Yingzhen]: I didn’t get this comment. Why BGP-LS here?
>
> s.1 usually includes RESTCONF
[Yingzhen]: added RESTCONF.
>
> s.1.1 out of date; the YANG module has the up to date description
[Yingzhen]: fixed.
>
> YANG
> four authors, three are mailto: one not
[Yingzhen]: fixed.
>
> MSD needs expanding in the YANG module as that will exist independent of the RFC
[Yingzhen]: fixed. Please let me know if you see places that need expanding.
>
> identity identifiers have a lot of 'base' which I think redundant
> 'RFC8491: Singling MSD ...'
>
> erld-msd I think back to front; I prefer msd-erld, msd-….
[Yingzhen]: changed the names.
>
> groupings that are only used once often get criticised by a YANG Doctor.  Quite right too IMO it just adds complexity and makes the I-D harder to read for no benefit that I can see.
>
[Yingzhen]: removed the grouping.

> Tom Petch
>
> Thanks,
> Yingzhen (on behalf of the co-authors)
>
> ________________________________
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Sunday, August 1, 2021 12:01 PM
> To: Acee Lindem <acee@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; Stephane Litkowski <slitkows.ietf@gmail.com>; Yingzhen Qu <yingzhen.qu@futurewei.com>
> Subject: New Version Notification for draft-qu-mpls-mpls-msd-yang-01.txt
>
>
> A new version of I-D, draft-qu-mpls-mpls-msd-yang-01.txt
> has been successfully submitted by Yingzhen Qu and posted to the
> IETF repository.
>
> Name:           draft-qu-mpls-mpls-msd-yang
> Revision:       01
> Title:          A YANG Model for MPLS MSD
> Document date:  2021-08-01
> Group:          Individual Submission
> Pages:          10
> URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-qu-mpls-mpls-msd-yang-01.txt&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2cc7aa1a9ead41568d1108d9551ecf5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637634413085880786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dxVGZrfMleDR%2B1%2BlkmEXN%2FRJOmL1zXLRD3xKBjNtOzI%3D&amp;reserved=0
> Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-qu-mpls-mpls-msd-yang%2F&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2cc7aa1a9ead41568d1108d9551ecf5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637634413085880786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=sOxeuBLa4ZSUV0to9%2F9SMrpQ2xOE%2Fkxq8hBiPeUlEUc%3D&amp;reserved=0
> Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-qu-mpls-mpls-msd-yang&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2cc7aa1a9ead41568d1108d9551ecf5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637634413085880786%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VX8Y40I3tUA%2BKolwyUUNTTV%2BMVt9s5l5MNXiEuIsjA8%3D&amp;reserved=0
> Diff:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-qu-mpls-mpls-msd-yang-01&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7C2cc7aa1a9ead41568d1108d9551ecf5f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637634413085890780%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SvVf6VTIySZnUBZCgCMfthT%2FSyqkb1gIoES7FYYZg8U%3D&amp;reserved=0
>
> Abstract:
>   This document defines a YANG data module augmenting the IETF MPLS
>   YANG model to provide support for MPLS Maximum SID Depths (MSDs) as
>   defined in RFC 8476 and RFC 8491.
>
>
>
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls