Subject: [mpls] fwd Re: mpls-rt review of draft-akiya-mpls-entropy-lsp-ping

From: Curtis Villamizar <[email-masked]>
Date: Fri, 17 Jan 2014 12:49:01 -0500

My bad.  Replied to wrong email with mpls WG not on the Cc.

Subject and message-id/reply-to searches might be unhappy but here it
is.  I hope the mailing list is OK with rfc822 mime type.

Curtis

Subject: Re: Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping
From: Loa Andersson <[email-masked]>
To: [email-masked]
Date: Fri, 17 Jan 2014 13:11:25 +0800

Curtis,

I can take the review as it is, but I prefer to have on the working
group mailing list. If it is OK to you, please send it.

/Loa

On 2014-01-17 13:08, Curtis Villamizar wrote:
> In message <[email-masked]>
> Loa Andersson writes:
>
>> Folks,
>>
>> This was the wrong document - I intended to have the review
>> done for draft-akiya-mpls-entropy-lsp-ping sorry for the confusion.
>>
>> All other cordinates correct!
>>
>> On 2014-01-03 14:44, Loa Andersson wrote:
>>> Sri, Xiaohu, Curtis and Dan,
>>>
>>> You have been selected as MPLS Review team reviewers for
>>> draft-akiya-mpls-entropy-lsp-ping-01.
>>>
>>> Note to authors: You have been CC'd on this email so that you can know
>>> that this review is going on. However, please do not review your own
>>> document.
>>>
>>> Reviews should comment on whether the document is coherent, is it
>>> useful (ie, is it likely to be actually useful in operational
>>> networks), and is the document technically sound?  We are interested
>>> in knowing whether the document is ready to be considered for WG
>>> adoption (ie, it doesn't have to be perfect at this point, but should be
>>> a good start).
>>>
>>> Reviews should be sent to the document authors, WG co-chairs and
>>> WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
>>> may be sent privately to only the WG chairs.
>>>
>>> Are you able to review this draft by January 20, 2014?
>>>
>>> Thanks, Loa
>>> (as MPLS WG chair)
>>
>> --
>>
>>
>> Loa Andersson                        email: [email-masked]
>
>
>
> Loa,
>
> Overall a good draft and should become a WG doc as it is an
> improvement to a fairly badly designed feature of MPLS Ping that
> remains fairly badly designed but now a little less broken for ELI/EL.
>
> I'm not sure the procedures that are defined work correctly if an LSR
> does load split on the label stack (or part of it) up to and then
> including the EL, but nothing after the EL.  There seems to be an
> assumption that only the EL is used if present.  The way the RFC 6790
> reads the search for entropy stops at the EL (a SHOULD that would have
> been better made a MUST).
>
> Some (big) issues:
>
>    {L=0, E=0} LSR load balances based on IP and does not push ELI/EL.
>    {L=0, E=1} LSR load balances based on IP and pushes ELI/EL.
>    {L=1, E=0} LSR load balances based on label and does not push ELI/EL.
>    {L=1, E=1} LSR load balances based on label and pushes ELI/EL.
>
> What about the case where the LSR load balances on both labels and on
> IP?  If the payload is IP, the entropy from the IP header is used *in
> addition to* the entropy from the label stack.
>
> There should also be a flag to indicate that the LSR will terminate
> the search for entropy at the EL as it SHOULD according to RFC 6790.
>
> The flags points to an issue with RFC 4379 even without ELI/EL that is
> still not addressed here.  What if the typical payload contains both
> additional labels (payload is MPLS) and IP under the labels and some
> LSR look at only the IP and some look at only the labels and some look
> at both and some that look at labels can only look at the top N or the
> bottom N labels.
>
> Also the max depth in RFC 4379 is inadequate since some LSR can look
> at labels up to some depth D1 and can find an IP header if it appears
> at up to some depth D2 and D1 != D2.  These two depths are not
> independent in RFC 4379.
>
> A few additional flags and values need to be carried if these cases
> are all to be covered.  OTOH, RFC 4379 works fine for a single vendor
> network if all their products behave in the same way.
>
> This draft acknowledges that there are some issues (including with
> E=0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them
> even though they are fixable:
>
>     In following conditions, initiating LSR may have lost the ability
>     to exercise specific ECMP paths.  Initiating LSR MAY continue with
>     "best effort".
>
>     o  Received echo reply contains empty multipath information.
>
>     o  Received echo reply contains {L=0, E=<any>} DS flags, but does
>        not contain IP multipath information.
>
>     o  Received echo reply contains {L=1, E=<any>} DS flags, but does
>        not contain label multipath information.
>
>     o  Received echo reply contains {L=<any>, E=1} DS flags, but does
>        not contain associated label multipath information.
>
>     o  IP multipath information types {2, 4, 8} sent, and received echo
>        reply with {L=1, E=0} in DS flags.
>
>     o  Multipath information type {10} sent, and received echo reply
>        with multipath information type other than {10}.
>
> On the topic of flags, the N bit was always problematic.  When TTL is
> incremented the LSR will behave as if the packet is IP, because it is.
>
> The flags and defined behavior for this failure is an improvement over
> RFC 4379 where the behavior was undefined both in terms of what to put
> in the reply and how the initiator should interpret it.
>
> Througout the document it is not clear what an IP load balancer is.
> For example:`
>
>     o  When initiating LSR is IP based load balancer (not pushing ELI/
>        EL), initialize EL_LSP=False.
>
> The initiating LSR may be a carrying MPLS traffic (ie: a PSC LSP).
> Therefore is may get traffic that already has an ELI/EL in the stack.
>
> This is not worded clearly for the case where the LSR is capable of IP
> based load balance but is not pushing an ELI/EL but it has already
> seen an ELI/EL on the stack.  Need to clarify whether the LSR is an
> "IP based load balancer" if it is capable of IP based load balance or
> if it would have done IP based load balance on this stack.
>
> The term "IP Based Load Balancer" is never defined.
>
> The term "Label Based Load Balancer" is never defined.
>
> It is not clear which to pick if an LSR can use both types of
> information as would be the case for many routers when no ELI/EL is
> found in the stack.
>
> In "9.  Unsupported Cases" you might as well admit "won't ever work
> for some vendor's equipment that uses the whole label stack to load
> balance plus can use IP stack".  The two unsupported cases are:
>
>     o  When one or more LSP transit node(s) performs label based load
>        balancing on a label that is not bottom-of-stack label when
>        Entropy Label Indicator is not included.
>
> A lot of equipment uses all of the labels.  Did you means does not use
> the bottom label?
>
>     o  When one or more LSP transit node(s) performs label based load
>        balancing on a label other than Entropy Label when Entropy Label
>        Indicator and Entropy Label pair is included.
>
> It is also legal (and I think preferred) to use all of the labels up
> to and including the first EL (but not the ELI and any other reserved
> label).  Did you means a label after the EL?
>
> Either these unsupported cases are worded wrong or something is very
> seriously wrong with LSP Ping.
>
> Some minor points:
>
> RFC 6424 should be mentioned as soon as RFC 4379 is mentioned in the
> intro since RFC 6424 changes RFC 4379 behavior and depricated a RFC
> 4379 TLV and replaces it.
>
>     When an MPLS echo request message is received containing a
>     FEC-Stack with an EL-FEC at the bottom of the FEC stack and is not
>     preceded by an entropy label, the responder must behave (for load
>     balancing purposes) as if the first word of the message were a
>     Pseudowire Control Word.
>
> This is asking for the DD-MAP or DS-MAP response to be constructed as
> if CW was at bottom, but doesn't read that way.  It reads as if
> forwarding was changed.
>
>     Note that this procedure only traces to the end of the MPLS LSP at
>     transport layer (e.g. LDP and/or RSVP).
>
> That is not what "transport layer" means to a lot of people.  Very bad
> wording.
>
>        *  Else initiating LSR MUST use multipath information type {2,
>           4, 8, 9}.
>
> Exactly what should it do if load balance is affected by *either*
> another label on the stack or a different IP under the stack?  What if
> both peices of information are used in creating load balance entropy
> (ie: what if the IP map depends on any additional labels)?
>
> Nits:
>
> s/indicate and entropy/indicate and entropy/
>
> In "5.2.  IP Based Load Balancer & Pushes ELI/EL" third bullet is a
> massive run-on paragraph.  Split into sub-bullets for the multiple
> case within it.  Probably good for other bullets containing more than
> one sentence starting with "If".
>
> probably plenty more nits that I missed.
>
> Curtis
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64