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

[tom petch <[e-mail]>]

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

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

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

>
> 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
>
> On 2019-02-20 19:30, tom petch wrote:
> > 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" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>;
> > <[e-mail]>
> > Sent: Wednesday, February 20, 2019 5:35 AM
> >
> >> 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 ([e-mail]). 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: [e-mail]
> >> Senior MPLS Expert
> >> Bronze Dragon Consulting             phone: [phone]
> >>
> >> _______________________________________________
> >> mpls mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mpls
> >
>
> --
>
>
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert
> Bronze Dragon Consulting             phone: [phone]