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

["Acee Lindem (acee)" <[e-mail]>]

Hi Tarek,

On 2/19/20, 1:00 AM, "mpls on behalf of Tarek Saad" <[e-mail] on behalf of tsaad=[e-mail]> wrote:

    Hi Tom,
    
    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" <[e-mail]> 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   

 
[ACEE] It is listed but since there is no asterisk by it so It must be expanded on first use.
Thanks,
Acee
    
    	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?
    [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.
    
    	  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.";
    	
    		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.
    	
    	  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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mpls