Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang

________________________________________
From: mpls <mpls-bounces@ietf.org> on behalf of tom petch <ietfc@btconnect.com>
Sent: 21 February 2020 16:30
To: Tarek Saad; Loa Andersson; mpls@ietf.org
Cc: mpls-chairs@ietf.org; draft-ietf-mpls-base-yang@ietf.org
Subject: Re: [mpls] MPLS wglc draft-ietf-mpls-base-yang

Tarek

progressing ... <tp> inline

________________________________________
From: Tarek Saad <tsaad@juniper.net>
Sent: 19 February 2020 06:00

Thanks much for your review and useful comments. We have posted a new revision -12 at https://tools.ietf.org/html/draft-ietf-mpls-base-yang-12 that addresses those. Let us know if you have further comments.
Also, see inline for responses on closure.

On 1/21/20, 7:38 AM, "tom petch" <ietfc@btconnect.com> wrote:

Some more technical thoughts on this I-D

        Abstract

        LSP is not in the RFC Editor list of 'so well known ...'
[TS]: it is listed at https://www.rfc-editor.org/materials/abbrev.expansion.txt

<tp> as Acee points out, it lacks the asterisk that says that no expansion is needed :-(

        s.2.1
           The other MPLS route(s) that are non-IP prefix routes are modelled by
           introducing a new "mpls" address-family RIB as per recommendation .

        Where is that?

<tp> I was looking for a reference for the recommendation - is this the routing RFC, RFC8349 s.5.2?

[TS]: Please refer to identity below defined in the model which has rt:address-family as base.
  identity mpls {
        base rt:address-family;
        description
          "This identity represents the MPLS address family.";
  }
        s.2.2
           interfaces-mpls:
                  A YANG grouping that describes the list of MPLS enabled interfaces
                  on a device.

           label-blocks:
                  A YANG grouping that describes the list of MPLS enabled interfaces
                  on a device.

        um?
[TS]: we corrected the description. See below:
NEW:
A YANG grouping that describes the list of assigned MPLS label blocks and its properties.

        YANG Module
                 Copyright (c) 2018 IETF Trust

                leaf loadshare {
        I  would  value a reference for this.
[TS]: rfc3031 section 3.11 and  3.12.

<TP>  well sort of; those sections talk about sharing across equal cost paths which seems somewhat simpler - I understand the YANG DESCRIPTION but would expect it to be described in an RFC somewhere.

          grouping interface-mpls-properties {
        ...
                  type boolean;
                  description
                   "'true' if mpls encapsulation is enabled on the interface.
                   'false' if mpls encapsulation is enabled  on the interface.";

<tp> so true means enabled and false means ..  enabled ; clear but logical?

                leaf mtu {  type uint32; description
                        "MPLS Maximum Transmission Unit (MTU) in bytes";

        um what is included in MTU here  c.f.draft-ietf-netmod-intf-ext-yang-07
        which  includes L2 header but not FCS in Layer 2 MTU;
        a reference might help
[TS]: includes L2 MTU + maximum MPLS label stack size. rfc3032 section 3.2.

<tp> well no; MTU does not appear in RFC3032 s.3.1; other terminology does and I want to map the terminology of this I-D - MTU- to the terminology of s.3.1

That is all

Tom Petch
</tp>

          grouping interfaces-mpls {    description "List of MPLS interfaces";
                list interface {   key "name";  description "List of MPLS
        interfaces";
                  leaf name {   type if:interface-ref;
                        description   "The name of a configured MPLS interface";

        no conditional so every RIP or dial up X.25 e.g.is going to get this:-( probably ok

          augment "/rt:routing" {
        ditto, although probably less significant
[TS]: added feature mpls, and added if-feature check under the augmentations.

          augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
                        + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
                description
                  "Augment 'simple-next-hop' case in IP unicast routes.";

        other I-D augment control plane/protocols/static-routes
[TS]: the MPLS Static model is a separate model that is described in draft-ietf-mpls-static-yang.

Regards,
Tarek

        Tom Petch

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls