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

From: tom petch <[email-masked]>
Date: Thu, 6 Aug 2020 09:30:36 +0100

This I-D breaks a MUST in RFC8349 Routing Management) and, as such, will 
not interoperate with devices that implement RFC8349 correctly.

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
> [email-masked] mailing lists by 2020-08-19. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: Tarek Saad <[email-masked]>
Date: Fri, 7 Aug 2020 16:48:27 +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" <[email-masked]> wrote:

		1

    Tom Petch

---

From: Tarek Saad <[email-masked]>
Date: Mon, 17 Aug 2020 16:40:32 +0000

Thanks Acee and Tom.
I'm merging the discussion on the other thread (titled: [mpls] [netmod] [Technical Errata) and providing the update.
We have uploaded a new revision https://tools.ietf.org/html/draft-ietf-mpls-base-yang-15 that addresses the comments previously raised.
Please let us know if there are further comments.

Regards,
Tarek (for co-authors)

    Tom Petch