Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard

Tarek Saad <tsaad.net@gmail.com> Fri, 07 August 2020 16:48 UTC

Return-Path: <tsaad.net@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 4BA5C3A0C21; Fri, 7 Aug 2020 09:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 kCxj8s63YIjJ; Fri, 7 Aug 2020 09:48:42 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 437B33A0C2B; Fri, 7 Aug 2020 09:48:31 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id x12so1757624qtp.1; Fri, 07 Aug 2020 09:48:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=pX29IUCj9dZwjP0i+lzK6l04F4MEXuihkvbq/Q/f01Q=; b=tqw+ip7VFb5GmwrF9ef8A8O2/GTcNm4zQU6VfRy95g3oykXGKBjVDwokC+/T4NLBYx CobEx1SqbpdsfkO8yaJOhlR/KysZZZ1GWRGa7x6LlVjG1mVsWhI166Y0muutYVUFzzW7 gAFZQ0rCYBgAJGFusGkLsOE4kMn3G5tTadGegGiHJceKJ5l759yx9oiYViFid/9f4fwM x3SJF1tyxo18PRBpxeYepEkfOi7E6cgYTEhrb6oBV+YcoNgIxL4DxGOG1BsRlUbAuDUx bT5leIaxl+fdg5y+HCQmEJfJYsM0ekcA36n5AVJMNZNnbjXiQi7ae4Za9x3/e1tbt3UP jPZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=pX29IUCj9dZwjP0i+lzK6l04F4MEXuihkvbq/Q/f01Q=; b=LdAjKOdEJWxg+kQ/9wrmWllNWrHFyrgqQBAfYAjjmoLyGnnEGzZRxHOXkmYlwl070t zVsmyZ2VfVs/WZjX/Rn2cXFXSMXM1dN/w8EmA+oSfUFyugYSQ/F2KCWtPEULBaguXQAo 7GtSLXDxBmiQnTXTqNBhVoDv+sBUFRGBXMDl1J+5sYmiJ0iXrko54zkDXrPfcP6JW+FJ sdehumo1+xOALghl9d7Z4ucLOj9YaDpOIbTe1HmGRJWNiW5nOVcbZ+gbAB4rpAP0saPD 18PBYSoroA/XUhTgBa6797NAfO1dB6b01fTfMJr1nu4FY/A5d5rO9Jhb5VQmHNa7yHve ATsQ==
X-Gm-Message-State: AOAM530ycIjXDw2wiNlLoWUW2ZFKC0DWe1n076ASd/heeC0TJHpagNQy 0E9/KiCPLtOl3KjAj0eCl5I=
X-Google-Smtp-Source: ABdhPJwx3AAimLOfrwSsxQTk4zVOCMBk/JCiAwyhHkOnOqjIAeHKDpn3IJVLM/SC7atbBwy9VCqiVA==
X-Received: by 2002:ac8:490d:: with SMTP id e13mr14586415qtq.198.1596818910226; Fri, 07 Aug 2020 09:48:30 -0700 (PDT)
Received: from SN6PR1901MB2158.namprd19.prod.outlook.com ([2603:1036:805:3::5]) by smtp.gmail.com with ESMTPSA id z68sm7027421qke.113.2020.08.07.09.48.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Aug 2020 09:48:29 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: tom petch <daedulus@btconnect.com>, "last-call@ietf.org" <last-call@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-base-yang@ietf.org" <draft-ietf-mpls-base-yang@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Thread-Topic: Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard
Thread-Index: ATU0Njg2qrZD37mlk1WCsQZB/ZDncjMwN0FCwNfG+n4=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Fri, 07 Aug 2020 16:48:27 +0000
Message-ID: <SN6PR1901MB2158900F6406EEA3AEFA4DFAFC490@SN6PR1901MB2158.namprd19.prod.outlook.com>
References: <159664704561.10058.12590600409549515735@ietfa.amsl.com> <5F2BBFAC.7060203@btconnect.com>
In-Reply-To: <5F2BBFAC.7060203@btconnect.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/qM11dH8XIv-nuWHkd6Z9v3w38zk>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-base-yang-14.txt> (A YANG Data Model for MPLS Base) to Proposed Standard
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: Fri, 07 Aug 2020 16:48:45 -0000

Thanks Tom.

As you mentioned, the authors shared their perspective on this at WGLC.
We believe it is proper for RFC8349 to allow augmentation with a proper leaf that identifies the route depending on RIB address-family - MPLS RIB routes are identified with a local label.
We submitted an errata against RFC8349 at https://www.rfc-editor.org/errata/eid6251

Regards,
Tarek (for the authors)

On 8/6/20, 4:31 AM, "tom petch" <daedulus@btconnect.com> wrote:


    This I-D breaks a MUST in RFC8349 Routing Management) and, as such, will 
    not interoperate with devices that implement RFC8349 correctly.
		1
    RFC8349 provides a YANG action to return the active route for a 
    destination address but omits the destination address, saying that 
    modules using this must augment the input with a leaf 
    destination-address.  This I-D augments the input with a leaf 
    local-label so implementations of RFC8349 that 'know' there will be a 
    leaf destination-address will fail to interoperate with this I-D.

    The authors said, at WGLC, that RFC8349 is wrong, that MPLS has label 
    not address and so the I-D must provide an augment with a label and 
    RFC8349 should change.  I disagree; I think that this is reading too 
    many semantics into an identifier.

    Tom Petch

    On 05/08/2020 18:04, The IESG wrote:
    >
    > The IESG has received a request from the Multiprotocol Label Switching WG
    > (mpls) to consider the following document: - 'A YANG Data Model for MPLS Base'
    >    <draft-ietf-mpls-base-yang-14.txt> as Proposed Standard
    >
    > The IESG plans to make a decision in the next few weeks, and solicits final
    > comments on this action. Please send substantive comments to the
    > last-call@ietf.org mailing lists by 2020-08-19. Exceptionally, comments may
    > be sent to iesg@ietf.org instead. In either case, please retain the beginning
    > of the Subject line to allow automated sorting.
    >
    > Abstract
    >
    >
    >     This document contains a specification of the MPLS base YANG model.
    >     The MPLS base YANG model serves as a base framework for configuring
    >     and managing an MPLS switching subsystem on an MPLS-enabled router.
    >     It is expected that other MPLS YANG models (e.g.  MPLS Label Switched
    >     Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS
    >     base YANG model.
    >
    >
    >
    >
    > The file can be obtained via
    > https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/
    >
    >
    >
    > No IPR declarations have been submitted directly on this I-D.
    >
    >
    >
    >
    >
    > _______________________________________________
    > IETF-Announce mailing list
    > IETF-Announce@ietf.org
    > https://www.ietf.org/mailman/listinfo/ietf-announce
    > .
    >