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

From: Yingzhen Qu <[email-masked]>
Date: Mon, 2 Aug 2021 04:41:37 +0000

Hi all,

We just submited a new version of the draft. Here is a summary of chagnes:

  *   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.

Thanks,
Yingzhen (on behalf of the co-authors)

________________________________
From: [email-masked] <[email-masked]>
Sent: Sunday, August 1, 2021 12:01 PM
To: Acee Lindem <[email-masked]>; Jeff Tantsura <[email-masked]>; Stephane Litkowski <[email-masked]>; Yingzhen Qu <[email-masked]>
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

---

From: tom petch <[email-masked]>
Date: Mon, 2 Aug 2021 10:01:05 +0000

From: mpls <[email-masked]> on behalf of Yingzhen Qu <[email-masked]>
Sent: 02 August 2021 05:41

Hi all,

<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?

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.

You specify two protocols for signalling MSD; why not BGP-LS?

s.1 usually includes RESTCONF

s.1.1 out of date; the YANG module has the up to date description

YANG
four authors, three are mailto: one not

MSD needs expanding in the YANG module as that will exist independent of the RFC

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-....

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.

Tom Petch

Thanks,

Abstract:

The IETF Secretariat

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 2 Aug 2021 15:44:50 -0700

Hi Tom,

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

Thanks,
Yingzhen

> On Aug 2, 2021, at 3:01 AM, tom petch <[email-masked]> wrote:
> 
[Yingzhen]: Good suggestion. I’ve made the change.
> 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…
[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.
> 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.
> 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.

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: tom petch <[email-masked]>
Date: Tue, 3 Aug 2021 11:04:50 +0000

From: Yingzhen Qu <[email-masked]>
Sent: 02 August 2021 23:44

Hi Tom,

<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
[Yingzhen]: fixed.
[Yingzhen]: fixed.

---

From: Yingzhen Qu <[email-masked]>
Date: Tue, 3 Aug 2021 22:49:37 -0700

Hi Tom,

Regarding node-msd, you can find its definition in section 2 and section 6 of RFC 8491. Draft-ietf-isis-mpls-elc (https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/) added “type-2” MSD-type. I will add a reference in the next version of the draft. It’s expected that there will be extensions in the future. Hence the node-msd is defined as a list.

The MSD portion was moved out of SR YANG because MSD is a characteristic of MPLS, it’s not limited to SR. 

Thanks,
Yingzhen

> On Aug 3, 2021, at 4:04 AM, tom petch <[email-masked]> wrote:
>