[mpls] Yangdoctors early partial review of draft-ietf-mpls-ldp-yang-01

Dean Bogdanovic <ivandean@gmail.com> Fri, 08 September 2017 13:10 UTC

Return-Path: <ivandean@gmail.com>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D84A1323B4; Fri, 8 Sep 2017 06:10:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Dean Bogdanovic <ivandean@gmail.com>
To: yang-doctors@ietf.org
Cc: mpls@ietf.org, draft-ietf-mpls-ldp-yang.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.60.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150487625250.17301.18089417716327090477@ietfa.amsl.com>
Date: Fri, 08 Sep 2017 06:10:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/IBGYqjiAG9HDuvGeFBjsPysNAp4>
Subject: [mpls] Yangdoctors early partial review of draft-ietf-mpls-ldp-yang-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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, 08 Sep 2017 13:10:52 -0000

Review is partially done. Another review request has been registered for
completing it.

Reviewer: Dean Bogdanovic
Review result: On the Right Track

In general, I like you design with base and extended model. Think it is a very
good approach in modeling and maybe I as author should have taken a similar
approach when modeling ACLs.

But there is a bit of confusion for me

Why are IPv4 and v6 separated? Why is IPv6 missing from the base model? The RFC
5036 is specifying both AF is the document. And you are mentioning that RFC
5036 is used for base model. Wy having same hierarchy but different namespaces?

4.1.1. Base

1. should 'discovery' be under 'global'?

Especially the 'interfaces' section. 'Interfaces' are directly attached to the
device. Compared to peers which is the remote end (either that be directly
connected peers, or peers that are more than 1 hop away). If peers are not
under global, it seems that 'discovery' and especially 'discovery/interfaces'
should not be under 'global'.

This applies to 'discovery/targeted' as well.

module: ietf-mpls-ldp
augment /rt:routing/rt:control-plane-protocols:
   +--rw mpls-ldp!
      +--rw global
      |  +--rw config
      |  |  +--rw capability
      |  |  +--rw graceful-restart
      |  |  |  +--rw enable?                boolean
      |  |  |  +--rw reconnect-time?        uint16
      |  |  |  +--rw recovery-time?         uint16
      |  |  |  +--rw forwarding-holdtime?   uint16
      |  |  +--rw lsr-id?             yang:dotted-quad
      |  +--rw address-families
      |  |  +--rw ipv4
      |  |     +--rw config
      |  |        +--rw enable?         boolean
      |  |        +--rw label-policy
      |  |           +--rw advertise
      |  |              +--rw egress-explicit-null
      |  |                 +--rw enable?   boolean
      |  +--rw discovery
      |     +--rw interfaces
      |     |  +--rw config
      |     |  |  +--rw hello-holdtime?   uint16
      |     |  |  +--rw hello-interval?   uint16
      |     |  +--rw interface* [interface]
      |     |     +--rw interface           mpls-interface-ref
      |     |     +--rw address-families
      |     |        +--rw ipv4
      |     |           +--rw config
      |     |              +--rw enable?   boolean

9.1 Base

   leaf peer-ldp-id {
     type yang:dotted-quad;
     description "Peer LDP ID.";
   }

Nit: "peer-" prefix needed?

Is this value different from peer LSR ID?

In general, I believe you are on the right path, but I don’t have deep LDP
knowledge, so can’t understand some of the nuances that you might have wanted
to address