Re: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt

[<[e-mail]>]

Hi authors,

Please find below some minor comments:

1) Abstract:
" In addition, this document introduces the Non-IGP Functional
   Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
   functional capabilities.  ELC is one of such non-IGP functional
   capabilities."

It's a matter of opinion but reducing the number of occurrences of " non-IGP functional capabilities" may improve the S/N ration.

2) 
   The format of the Router Non-IGP Functional Capabilities Sub-TLV is  as follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Type=TBD1  |    Length=4   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The sub-TLV is not hard coded/defined with a length of 4, hence this value should not be part of the definition.

3)
"Length: Indicates the length of the value portion in octets and  will be a multiple of 4 octets"

Possibly :s/will/MUST
Please specify the error handling. (e.g. disregards the whole sub-TLV, disregards the last 1 to 3 octets, accept the whole sub-TLV...)


4)
"One bit of the Non-IGP Functional Capability Bits (Bit 0 is desired)  is to be assigned by the IANA for the ELC [RFC6790]."

Since this document defines the new sub-TLV, it can freely do any allocation itself.

5)
"The registration procedure is "Expert Review" as defined in   [RFC8126]."

You may want to read RFC 8126 https://tools.ietf.org/html/rfc8126#section-4.5
Which, In particular, states:
" The registry's
   definition needs to make clear to registrants what information is
   necessary.  

  [...]

   The required documentation and review criteria, giving clear guidance
   to the designated expert, should be provided when defining the
   registry.  It is particularly important to lay out what should be
   considered when performing an evaluation and reasons for rejecting a
   request.  It is also a good idea to include, when possible, a sense
   of whether many registrations are expected over time, or if the
   registry is expected to be updated infrequently or in exceptional
   circumstances only. "

6)
"This capability, referred to as Entropy  Readable Label Depth (ERLD) as defined in  [I-D.ietf-mpls-spring-entropy-label] "

This probably calls for this document to be a normative reference.


"   A new MSD-type of the Node MSD b-TLV
   [I-D.ietf-isis-segment-routing-msd], called ERLD is defined to
   advertise the ERLD of a given router."

May be adding the reference to the document defining the ERLD:
OLD: advertise the ERLD
NEW: advertise the ERLD [I-D.ietf-mpls-spring-entropy-label]

7)
"If a router has
   multiple line cards, the router MUST NOT announce the ELC [RFC6790]
   unless all of its linecards are capable of processing ELs."

May be you mean
OLD: all of its linecards
OLD: all of the linecards of the links advertised as IS-IS adjacencies.

Regards,
--Bruno

 > -----Original Message-----
 > From: Lsr [mailto:[e-mail]] On Behalf Of [e-mail]
 > Sent: Tuesday, July 31, 2018 4:07 PM
 > To: [e-mail]
 > Cc: [e-mail]
 > Subject: [Lsr] I-D Action: draft-ietf-isis-mpls-elc-05.txt
 > 
 > 
 > A New Internet-Draft is available from the on-line Internet-Drafts directories.
 > This draft is a work item of the Link State Routing WG of the IETF.
 > 
 >         Title           : Signaling Entropy Label Capability and Entropy Readable Label Depth Using
 > IS-IS
 >         Authors         : Xiaohu Xu
 >                           Sriganesh Kini
 >                           Siva Sivabalan
 >                           Clarence Filsfils
 >                           Stephane Litkowski
 > 	Filename        : draft-ietf-isis-mpls-elc-05.txt
 > 	Pages           : 7
 > 	Date            : 2018-07-29
 > 
 > Abstract:
 >    Multiprotocol Label Switching (MPLS) has defined a mechanism to load
 >    balance traffic flows using Entropy Labels (EL).  An ingress Label
 >    Switching Router (LSR) cannot insert ELs for packets going into a
 >    given tunnel unless an egress LSR has indicated via signaling that it
 >    has the capability of processing ELs, referred to as Entropy Label
 >    Capability (ELC), on that tunnel.  In addition, it would be useful
 >    for ingress LSRs to know each LSR's capability of reading the maximum
 >    label stack depth and performing EL-based load-balancing, referred to
 >    as Entropy Readable Label Depth (ERLD), in the cases where stacked
 >    LSPs are used for whatever reasons.  This document defines mechanisms
 >    to signal these two capabilities using IS-IS.  These mechanisms are
 >    useful when the label advertisement is also done via IS-IS.  In
 >    addition, this document introduces the Non-IGP Functional
 >    Capabilities Sub-TLV for advertising IS-IS router's actual non-IGP
 >    functional capabilities.  ELC is one of such non-IGP functional
 >    capabilities.
 > 
 > 
 > The IETF datatracker status page for this draft is:
 > https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/
 > 
 > There are also htmlized versions available at:
 > https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-05
 > https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-05
 > 
 > A diff from the previous version is available at:
 > https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-mpls-elc-05
 > 
 > 
 > Please note that it may take a couple of minutes from the time of submission
 > until the htmlized version and diff are available at tools.ietf.org.
 > 
 > Internet-Drafts are also available by anonymous FTP at:
 > ftp://ftp.ietf.org/internet-drafts/
 > 
 > _______________________________________________
 > Lsr mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/lsr

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.