Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Qin,

Thank you for the review comments.

Apologies for the late reply on action on the WG LC comments.

Please see inline ...

> -----Original Message-----
> From: netmod <[e-mail]> On Behalf Of Qin Wu
> Sent: 19 August 2019 10:23
> To: Kent Watsen <[e-mail]>; [e-mail]
> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> I have reviewed this document and have a few comments as follows:
> 1. Suggest to add references for imported module
[RW] 

I presume that you mean:

  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model For Interface Management";
  }

If so, this is now done.


 2. Suggest to add a
> paragraph in the section 5 to explain which common type or type in
> specific module is imported
[RW] 

Please can you clarify this comment, because I'm not sure what you are requesting here.  I've left an open issue to track this:  https://github.com/netmod-wg/interface-extensions-yang/issues/21


 3. s/ reference "Internet draft: draft-ietf-
> netmod-intf-ext-yang-07";/ reference "RFCxxxx: Common Interface Extension
> YANG Data Models";
[RW] 

I've changed the references to:

  revision 2019-11-04 {
    description
      "Initial revision.";

    reference
      "RFC XXXX, Common Interface Extension YANG Data Models";
  }

And

  feature carrier-delay {
    description
      "This feature indicates that configurable interface
       carrier delay is supported, which is a feature is used to
       limit the propagation of very short interface link state
       flaps.";
    reference "RFC XXXX, Section 2.1 Carrier Delay";
  }


 4. I am not sure L2 MTU is common attribute applicable
> to all packet frame based interface, in most case, we are using L3 MTU.
> >From the definition of L2 MTU
> " A layer 2 MTU configuration leaf (l2-mtu) is provided to specify the
> maximum size of a layer 2 frame that may be transmitted or received on an
> interface. "
> I am wondering this L2 MTU is related to Maximum Receive Unit defined in
> RFC4638. If the answer is YES, I would suggest to rename it, but it is
> still not clear whether it should be An common attribute part of ietf-
> interfaces-common.
> If it is No, I am wondering why L2 MTU is not augmented from IP address
> management module which define common MTU attribute, also it is not clear
> to me if ietf-interfaces-common Is positioned as technology specific
> model? When we choose to use MTU defined in RFC8344 and when we should
> choose to use L2 MTU defined in draft-ietf-netmod-intf-ext-yang-07.
> I think L3 MTU is common and widely deployed and supported by most of
> implementations. But go to L2 MTU:
> "
> The payload MTU available to higher layer protocols is either derived from
> the layer 2 MTU, taking into account the size of the layer 2 header, or is
> further restricted by explicit layer
> 3 or protocol specific MTU configuration."; "
> You add a lot of flexibility or multiple options, therefore I think it is
> hard to implement it.
[RW] 
Some platforms define MTU in terms of L3, and derive the maximum L2 frame size from that value.
Other platforms define MTU in terms of L2 frame size, and derive the maximum L3 packet size from that value.

It is also useful to be able to see (e.g. in operational state) the actual maximum L2 frame that may be sent/received on an interface.

Further, if a service is L2 based then describing the maximum L2 frame that can be forwarded is more meaningful that describing the L3 payload of the data that may be carried, particularly if the size of the L2 header may not be of fixed size (e.g. depending on how many VLAN tags are configured).

I've changed the name and definition of L2 MTU to:

    /*
     * Allows the maximum frame size to be configured or reported.
     */
    leaf max-frame-size {
      if-feature "max-frame-size";
      type uint32 {
        range "64 .. max";
      }
      description
        "The maximum size of layer 2 frames that may be transmitted
         or received on the interface (including any frame header,
         maximum frame payload size, and frame checksum sequence).

         If configured, the max-frame-size also limits the maximum
         frame size of any child sub-interfaces.  The MTU available
         to higher layer protocols is restricted to the maximum frame
         payload size, and MAY be further restricted by explicit
         layer 3 or protocol specific MTU configuration.";
      
      reference "RFC XXXX, Section 2.5 Maximum Frame Size";
    }

But I'll start a separate thread to close on the l2-mtu/max-frame-size issue (and the others).

Thanks,
Rob



> 
> -Qin
> -----Original Message-----
> From: netmod <[e-mail]> On Behalf Of Kent Watsen
> Sent: 2019. július 10., szerda 2:15
> To: [e-mail]
> Subject: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07
> 
> All,
> 
> This starts a twelve-day working group last call for
> draft-ietf-netmod-intf-ext-yang-07
> 
> The working group last call ends on July 21 (the day before the NETMOD 105
> sessions).  Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is
> ready for publication", are welcome!  This is useful and important, even
> from authors.
> 
> Thank you,
> NETMOD Chairs
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod