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

[tom petch <[e-mail]>]

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


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

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