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

[Kireeti Kompella <[e-mail]>]

Hi Curtis,

Thanks for your comments!  I'm fine with the fixes for Nit 1 and 2.

See inline for the "More than a nit".

On Jun 14, 2012, at 10:54 , Curtis Villamizar wrote:

> 
> 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).  

Let me see if I understand: even if an LSR is simply label switching on the top label, it may search the top 6-8 labels for one that has a BoS bit set?  And do funky things if such is not found?

>   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.

I'd be more afraid of setting BOS to 1 in the middle of the label stack than of legacy LSRs dropping packets with too many labels (for them).  The former violates the MPLS label architecture; the latter is a particular implementation issue.

>   It might be better to put BOS (S=1) at ELI, only if it is the
>   second or later ELI in the stack.  

This is still scary; moreover, in case of hierarchical tunnels or CsC VPNs, different LSRs may insert the ELI+EL pair.

Good point for the MPLS WG at large to mull over.  My inclination is to leave this as it currently is, or at most point out the legacy LSR issue without attempting to fix it.

Kireeti.

> 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.
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls