Subject: [mpls] Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg

From: Loa Andersson <[email-masked]>
Date: Wed, 20 Feb 2019 13:35:40 +0800

Working Group,

This is to start a two week poll on adopting
draft-zheng-mpls-lsp-ping-yang-cfg-10
as a MPLS working group document.

Please send your comments (support/not support) to the mpls working
group mailing list ([email-masked]). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

We have done an IPR poll for this document. All the co-authors have
responded to the IPR poll that they are unaware of any IPRs that relates
to this draft.

All, the contributors (with one exception) have responded to the IPR
poll that they are unaware of any IPRs that relates to this draft.

The contributor that has not responded has left his former employment
and is no longer on the MPLS wg mailing list. The wg chairs has decided
to go ahead with the wgap. If there is any concerns about this, please
speak up in the mailing list.

There are no IPR disclosures against this document.

The working group adoption poll ends March 6, 2019.

/Loa

mpls wg co-chair
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: tom petch <[email-masked]>
Date: Wed, 20 Feb 2019 11:30:34 +0000

Not support

The YANG module is very weak on references which makes it hard for me to
be sure but there seems to be a mismatch between e.g. FEC classes in
RFC8029 and the YANG module.

Thus RFC809 has
           1          5         LDP IPv4 prefix
with a one byte prefix length and four byte prefix.

The YANG module has
      enum ip-prefix {
        value "0";
        description "IPv4/IPv6 prefix";
and
        choice target-fec {
          case ip-prefix {
            leaf ip-address {
              type inet:ip-address;
              description "IPv4/IPv6 Prefix";
where ip-address has no concept of prefix length how can that be
configured?.

There are many such instances IMHO; having references in the YANG module
to sections of RFC8029 would make this more apparent.

Tom Petch

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>
Sent: Wednesday, February 20, 2019 5:35 AM

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

---

From: Loa Andersson <[email-masked]>
Date: Thu, 21 Feb 2019 08:40:46 +0800

Tom,

Much as I appreciate your comments, and I agree with the technical
aspects of them. The references and the inconsistencies should be
fixed. However, I have a little bit different view of what should
be done.

It is clear that we need a YANG module for LSP Ping.

It is unlikely that there will be another document.

This document has been very slow developing, the first version is
from 2015.

I think that we should say that this is "a good enough starting
point", and that there are thing that need to be fixed before
publication, e.g the RPCs mentioned by Acee, and the lack of references
and the potential inconsistencies pointed out by you.

To put the working group in control of the draft and make sure that it
progress well I want to adaopt it as a working group document. The
only thing I believe is necessary is that the authors acknowledge that
the issues pointed out needs to be addressed.

/Loa

--

---

From: tom petch <[email-masked]>
Date: Thu, 21 Feb 2019 12:17:20 +0000

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
Sent: Thursday, February 21, 2019 12:40 AM

> and the potential inconsistencies pointed out by you.

Which is where we part company.  After three years, and 10 revisions, I
look for more.  In particular, I see too much discrepancy between the
YANG module and RFC8029, although, as I said, the lack of references and
the change of identifiers for FEC classes and the conflation of FEC
classes,  makes comparison difficult for me.

RFC8029 list 16 FEC, this I-D six; Why the elision? What is the mapping?

This I-D uses enumeration and provides a numeric value.  The numeric
value is not present on the wire and so usually is not specified in a
YANG module, except as documentation - here the values specified bear no
relationship to the RFC and so confuse me  (Common practice now is to
use YANG identity rather than enumeration although neither are ideal).

Taking a guess at the mapping, compared to RFC8029,

          case ip-prefix {
lacks prefix length

          case bgp {
 lacks prefix length

          case rsvp {
I struggle with - the I-D only defines a string, the RFC
    IPv4 tunnel end point address
    Tunnel ID
    Extended Tunnel ID
    IPv4 tunnel sender address
    LSP ID

          case vpn {
defines  leaf vrf-name { type uint32;  "Layer3 VPN Name";
            leaf vpn-ip-address type inet:ip-address; "Layer3 VPN IPv4
Prefix";
which lacks prefix length and Route Distinguisher (8 octets)  compared
to the RFC

          case pw
has
   leaf vcid {  type uint32;
while the RFC has
    Sender's PE IPv4 Address
    Remote PE IPv4 Address
    PW ID
    PW Type

          case vpls {
appears to be an (unfortunate) renaming of FEC129 and specifies
         leaf vsi-name { type string; description "VPLS VSI";
where the RFC has AGI AII etc

So we agree that we need the ability to configure the functions of
RFC8029, but this I-D seems somewhat removed from that, too far to
become a WG I-D IMHO.

Tom Petch

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Feb 2019 09:01:44 -0800

Hi Tom,
much appreciate your comments, suggestions.
The original source for the model was RFC 4379, not RFC 8029. I understand
that a lot of work is ahead for us with the model, document. I hope that
the WG will actively participate and contribute to complete the model in a
reasonable time.

Regards,
Greg

---

From: tom petch <[email-masked]>
Date: Fri, 22 Feb 2019 17:19:12 +0000

----- Original Message -----
From: "Greg Mirsky" <[email-masked]>
Sent: Thursday, February 21, 2019 5:01 PM

Greg

I look forward to it.

As is probably clearer in my second e-mail, what I hope for is to be
able to go readily from the functions in RFC8029 to see how to configure
all the fields therein from this I-D, and likewise to go from this I-D
back to RFC8029 for more information on a particular object; and where
the YANG module does not facilitate configuration, perhaps the value is
implicit or that part of the functionality is not supported at this
time, then to be told that in the I-D.

Tom Petch

> Regards,
> Greg
>
> On Thu, Feb 21, 2019 at 4:17 AM tom petch wrote:
>
> > > > The YANG module is very weak on references which makes it hard
for
> > me to
> > > > There are many such instances IMHO; having references in the
YANG
> > module
> > > >> motivation for your support/not support, especially if you
think
> > that
> > > >> responded to the IPR poll that they are unaware of any IPRs
that
> > > > relates
> > > >> to this draft.
> > > >>
> > > >> All, the contributors (with one exception) have responded to
the
> > IPR