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

From: Ross Callon <[email-masked]>
Date: Thu, 14 Jun 2012 11:31:30 -0400

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)

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jun 2012 13:54:59 -0400

In message <[email-masked]>
Ross Callon writes:
 
> 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.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 14 Jun 2012 13:39:17 -0700

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:

>   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

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.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 14 Jun 2012 20:30:35 -0400

Kireeti,

Thanks for the reply.  I'm fine with taking the nits and leaving the
"More than a nit" comment alone as you suggested.  You may be right
about the BOS in the middle of stack being worse than the potential
problem it would be trying to avoid.

Curtis

In message <[email-masked]>
Kireeti Kompella writes:

Hi Curtis,

Kireeti.