Re: [mpls] WG last call on draft-ietf-mpls-entropy-label-03

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
Ross Callon writes:
 
> Working Group;
>  
> This is to start a two week working group last call on:
>  
> - draft-ietf-mpls-entropy-label-03
>  
> Please send comments to the mpls working group list.
>  
> The working group last call ends June 28, 2012.
>  
> Also, please note that there was an IPR disclosure on this document
> sent to the MPLS mailing list yesterday, with the subject line "IPR
> Disclosure: Cisco's Statement of IPR Related to
> draft-ietf-mpls-entropy-label-03".
>  
> Thanks, Ross
> (as MPLS WG co-chair)


Ross,

I just reread the new draft.  It is very clear.  It adds a worthwhile
and well thought out mechanism to MPLS.

Two nits, one potential problem but maybe one that is best addressed
later if problems with legacy LSR occur.

IMHO - Illustrative examples are usually put in appendices.  Maybe
section 8 should be moved to an appendix (it would become Appendix B).

Curtis


Nit 1:

 Old:

   The term 'label' is used both for the entire 32-bit label and the 20-
   bit label field within a label.  It should be clear from the context
   which is meant.

 Better:

   The term 'label' is used both for the entire 32-bit label stack
   entry and the 20-bit label field within a label stack entry.  It
   should be clear from the context which is meant.

 Why:

   Label stack entry and label field are completely unambiguous and
   are the terms used in RFC 3032.  Using label alone is common and
   this paragraph is a good clarification, but it is a better
   clarification if the full terms that "label" is replacing are
   spelled out.

Nit 2:

 Old:

   This is accomplished by REQUIRING that the label
   immediately preceding an entropy label (EL) in the MPLS label stack
   be an 'entropy label indicator' (ELI).

 New:

   This is accomplished by REQUIRING that the label immediately
   preceding an entropy label (EL) in the MPLS label stack be an
   'entropy label indicator' (ELI), where preceding means closer to
   the top of the label stack (farther from bottom of stack
   indication).

 Why:

   The existing wording might not be as clear to the MPLS neophyte
   that preceding implies the order of stack processing.  AFAIK
   "preceding" is not defined anywhere.

More than a nit (maybe):

 Old:

   b.  X MAY insert several entropy labels in the stack (each, of
       course, preceded by an ELI), potentially one for each
       hierarchical tunnel, provided that the egress for that tunnel
       has indicated that it can process ELs for that tunnel.

 Potential issue:

   Many existing LSR are unable to handle label stacks in excess of a
   small number of labels (six, eight being common).  In some LSR when
   no BOS is found in a limited depth search, unexpected behaviour may
   result, possibly packet discard.  This may be a reason for BOS=1 at
   ELI, but a better alternative exists.

   It might be better to put BOS (S=1) at ELI, only if it is the
   second or later ELI in the stack.  This keeps stack depth down for
   older LSR that may have a problem with it.  Having popped an ELI
   and EL at an egress, the S-bit of the next EL can be changed to
   S=0.

   This would result in:

    No RFC4928 concerns if EL values avoid 4 or 6 in the first nibble
    of an EL that follows an ELI with BOS=1.

    Legacy load balance continues to work, acting on the top ELI.

    Label stack depth seen by legacy LSR is never increased by more
    than three labels (first EL and ELI with BOS=0, and second ELI
    with BOS=1).

   BTW - If you leave this out, it will simplify things.  If you add
   it, it just provides a means of addressing problems with legacy LSR
   should those problems be significant.

   I am concerned due to prior discussions with chip vendors about
   their handling of deep label stacks and hashing label stacks, with
   "no BOS found" being an error.  I am also concerned because one
   chip vendor claimed that hashing on more than three labels would be
   easy - just cycle the packet through twice (and get half the PPS,
   thinking that was OK on the basis that such packets might be rare).
   Even in cases where we saw issues in evaluation and were
   sufficiently interested to point out the issues and ask for
   changes, others have used earlier iterations of these chips.
   If I remember correctly, one chip vendor circa 2006 thought that a
   max of two labels is all that was ever needed, LDP and PW, based on
   a prior customer input (all that customer thought they needed).

   Perhaps this handling of BOS at ELI can be included as an optional
   behavior but if so, another capability must be indicated.  The
   operation can be summarized as "hiding a prior EL and the rest of
   stack when adding an additional ELI and EL if the egress is able to
   reverse the process".  The capability can be indicated with two
   values of "Type" in LDP signaling.  It would require two bits in
   the Attribute Flags TLV for RSVP-TE signaling.

   The downside to this is constraining the depth of the search for
   another EL after ELI, EL POP.  It would be best if the egress could
   indicate how deep the next EL could be.  This means more than two
   Attribute Flags TLV bits or two values of Type in LDP ELC.
   Possibly an extension could be proposed later if problems occur.