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

Greg Mirsky <gregimirsky@gmail.com> Thu, 21 February 2019 17:01 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC961130DEF; Thu, 21 Feb 2019 09:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJPcNo435UV7; Thu, 21 Feb 2019 09:01:56 -0800 (PST)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B5D1200D7; Thu, 21 Feb 2019 09:01:55 -0800 (PST)
Received: by mail-lj1-x231.google.com with SMTP id q128so24571300ljb.11; Thu, 21 Feb 2019 09:01:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gHm8w6iZOEq4wzcbQGgpo+NHM+OljxlpHqsY3+Jy/iY=; b=WoIi1Seaq4NeAr6u77FWrEym6mdcJPUEWW9+X7xsBmb2fDdQgllbrX0z4GlsIskoJ5 noLHGv/ZFdblJ5vKPhO5X2UHxQ0F80hXe8D+G8ZFraVH9yV+jxngpg2OfvPVLSDQYSZc 7N2KALXn368lDZxlECeNdUOq/G1zxEZlHsNdBTr4Ogxmb62V09+W2INz+jWDELoC3hPC kHUuIzWS4PyZOlQNQmEQ9Ar8dDY+LrOMp5mkhtSHJDDH58YRi2VX/+s5sfpRvPHMP6YJ qKnSGDxzgQD/YvmC16NfUP+GakQL2gLiDwPlHF8fUJZ8qYzTVV0Ug3rrUVAOHg/OfwSV GCAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gHm8w6iZOEq4wzcbQGgpo+NHM+OljxlpHqsY3+Jy/iY=; b=Olc/vApaygs4NvDhfUIam62YF6Fqx13NgrdYh+9KMLjwNZgmizwVYWBAXhia0dzXO0 XyBi0eoOB7NOj60MVRw2u1w4UXgIpgcfYRb1bzMso0qgOHz0MVnesuzvsMxAsg5T2yR3 yeA1c5RU4Xuls3klxTq6RUMi7a+dj5rVxdIUXGtSeVP3utS6ZyWKhyhL5oJZtznEWVhy GM/IKHNdv8e0b8khz1ajZIzeh8UcYUtYp0hfSp4E/SLOLvyoAxyOzrhXd9ZbQ33dE4nA k3ppra/a2Uwm+/iodztrN66odCE65a5B4AcPF2wjFu+q/PrCcAJ34NupP5IixqEL/T2I qAcA==
X-Gm-Message-State: AHQUAubvVmGmBNTuKsjDykYluFNwitCSHYyq11hOFq9CfXPcZlkwW7+Q /6GTI/CLdeLOSrjVTmD08MGrqbGkU8QR4zYU7QI=
X-Google-Smtp-Source: AHgI3IZEAiksJagQEjuVEl6RRHr6vnn/NLfYbZ42JBL/YDvb8NQoLtsbzJW+5HqrfT0o7QkVYB0eb871Rp52HWXMWNw=
X-Received: by 2002:a2e:8446:: with SMTP id u6-v6mr24665903ljh.74.1550768513409; Thu, 21 Feb 2019 09:01:53 -0800 (PST)
MIME-Version: 1.0
References: <98db7e71-6152-1335-8ca0-b5ae67b8a4b6@pi.nu> <020301d4c90f$748bd300$4001a8c0@gateway.2wire.net> <c33a19a1-2578-8182-1d50-fc6fae20ccf9@pi.nu> <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net>
In-Reply-To: <030301d4c9df$2602e180$4001a8c0@gateway.2wire.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 21 Feb 2019 09:01:44 -0800
Message-ID: <CA+RyBmVomr+uMK7h5a-dbqh2DibPOuFeOT-G3AUsHKjDn9jriw@mail.gmail.com>
To: tom petch <ietfc@btconnect.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Loa Andersson <loa@pi.nu>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org" <draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ee9e105826a6e0f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_B1UGEG3cdg2XuERsgIm8uyqRiM>
Subject: Re: [mpls] Working Group Adoption Poll on draft-zheng-mpls-lsp-ping-yang-cfg
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 17:02:00 -0000

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 <ietfc@btconnect.com> wrote:

> ----- Original Message -----
> From: "Loa Andersson" <loa@pi.nu>
> 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" <loa@pi.nu>
> > > To: <mpls@ietf.org>
> > > Cc: <mpls-chairs@ietf.org>rg>;
> > > <draft-zheng-mpls-lsp-ping-yang-cfg@ietf.org>
> > > 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 (mpls@ietf.org). 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: loa@pi.nu
> > >> Senior MPLS Expert
> > >> Bronze Dragon Consulting             phone: +46 739 81 21 64
> > >>
> > >> _______________________________________________
> > >> mpls mailing list
> > >> mpls@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/mpls
> > >
> >
> > --
> >
> >
> > Loa Andersson                        email: loa@pi.nu
> > Senior MPLS Expert
> > Bronze Dragon Consulting             phone: +46 739 81 21 64
>
>