From: Kireeti Kompella <kireeti@juniper.net>
To: "curtis@occnc.com" <curtis@occnc.com>
Date: Thu, 14 Jun 2012 13:39:17 -0700
Thread-Topic: [mpls] WG last call on draft-ietf-mpls-entropy-label-03
Thread-Index: Ac1KbcTJmAnm8kyrQxehXvfULlyugA==
Message-ID: <F7873C4D-5650-43B6-9374-37D9D5C55D9D@juniper.net>
References: <201206141754.q5EHsxFx027014@gateway.ipv6.occnc.com>
In-Reply-To: <201206141754.q5EHsxFx027014@gateway.ipv6.occnc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] WG last call on draft-ietf-mpls-entropy-label-03
Precedence: list

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:

>=20
> In message <DF7F294AF4153D498141CBEFADB17704C7117E47B5@EMBX01-WF.jnpr.net=
>
> Ross Callon writes:
>=20
>> Working Group;
>>=20
>> This is to start a two week working group last call on:
>>=20
>> - draft-ietf-mpls-entropy-label-03
>>=20
>> Please send comments to the mpls working group list.
>>=20
>> The working group last call ends June 28, 2012.
>>=20
>> 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".
>>=20
>> Thanks, Ross
>> (as MPLS WG co-chair)
>=20
>=20
> Ross,
>=20
> I just reread the new draft.  It is very clear.  It adds a worthwhile
> and well thought out mechanism to MPLS.
>=20
> Two nits, one potential problem but maybe one that is best addressed
> later if problems with legacy LSR occur.
>=20
> IMHO - Illustrative examples are usually put in appendices.  Maybe
> section 8 should be moved to an appendix (it would become Appendix B).
>=20
> Curtis
>=20
>=20
> Nit 1:
>=20
> Old:
>=20
>   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.
>=20
> Better:
>=20
>   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.
>=20
> Why:
>=20
>   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.
>=20
> Nit 2:
>=20
> Old:
>=20
>   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).
>=20
> New:
>=20
>   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).
>=20
> Why:
>=20
>   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.
>=20
> More than a nit (maybe):
>=20
> Old:
>=20
>   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.
>=20
> Potential issue:
>=20
>   Many existing LSR are unable to handle label stacks in excess of a
>   small number of labels (six, eight being common). =20

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=3D1 at
>   ELI, but a better alternative exists.

I'd be more afraid of setting BOS to 1 in the middle of the label stack tha=
n of legacy LSRs dropping packets with too many labels (for them).  The for=
mer violates the MPLS label architecture; the latter is a particular implem=
entation issue.

>   It might be better to put BOS (S=3D1) at ELI, only if it is the
>   second or later ELI in the stack. =20

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 lea=
ve this as it currently is, or at most point out the legacy LSR issue witho=
ut 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=3D0.
>=20
>   This would result in:
>=20
>    No RFC4928 concerns if EL values avoid 4 or 6 in the first nibble
>    of an EL that follows an ELI with BOS=3D1.
>=20
>    Legacy load balance continues to work, acting on the top ELI.
>=20
>    Label stack depth seen by legacy LSR is never increased by more
>    than three labels (first EL and ELI with BOS=3D0, and second ELI
>    with BOS=3D1).
>=20
>   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.
>=20
>   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).
>=20
>   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.
>=20
>   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.
>=20
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls