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

[Greg Mirsky <[e-mail]>]

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

On Thu, Feb 21, 2019 at 4:17 AM tom petch <[e-mail]> wrote:

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