Subject: Re: [mpls] Correction: mpls-rt review for draft-akiya-mpls-entropy-lsp-ping Was: Re: mpls-rt review of draft-ietf-mpls-proxy-lsp-ping

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Sun, 19 Jan 2014 17:02:49 +0000

Hi Curtis,

Thanks for detailed comments.

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

Assumption here is that label stack up to ELI/EL is constant for LSP tracing purpose, thus defined procedure will work whether transit LSR load balances on just (EL) or (label stack up to EL + EL). This assumption is most probably worth being mentioned in the document, and we will plan to do so.

The other tricky aspect depends on the outcome of draft-ravisingh-mpls-el-for-seamless-mpls. If multiple ELI/ELs are allowed in the label stack, and there are no clear defined forwarding rule on load balancing in that case, then defined procedures will not work, since we now have 2 (or more) non-constant values. I spoke to R. Singh and Y. Shen at Vancouver and communicated this concern on from OAM perspective.

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

You are right, that is still allowed by RFC6790.

[snip]
   Some transit LSRs look beyond the label stack for better load-
   balancing information.  This is a simple, backward-compatible
   approach in networks where some ingress LSRs impose ELs and others
   don't.  However, this is of limited incremental value if an EL is
   indeed present and requires more packet processing from the LSR.  A
   transit LSR MAY choose to parse the label stack for the presence of
   the ELI and look beyond the label stack only if it does not find it,
   thus retaining the old behavior when needed, yet avoiding unnecessary
   work if not needed.
[snip]

Adding LSP traceroute support for such will require [even more] complexities in the tools, which I personally would prefer to avoid if possible. I'd like to hear from WG on this, particularly those implementing ELI/EL. If there are any vendors looking at EL + IP for load balancing when EL is present, and if we want this scenario to also be supported by LSP traceroute, then we need to address this.

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

Wouldn't such flag potentially cause load balancing deviation between traffic vs. MPLS echo request?

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

Prior to this draft, supported scenarios were:
1. LSP which all LSR load balances just on IP as entropy.
2. LSP which all LSR load balances just on label stack as entropy.

With this draft, we intend to add support for following scenario.
3. LSP which all LSR load balances on IP as entropy OR label stack as entropy (assuming constant label stack + one EL).
4. Stitched/Hierarchical LSPs with ELI/EL push/pop operations by transit nodes.

Which both scenario a very likely realistic scenario.

Agree that there are many load balance implementations possibilities. I wish there was a clear load balance rules defined from the beginning. I also wish there _is_ a clear load balance rules defined today ... is there one? Without clear defined rules, OAM is placed in a very difficult position: i.e. solving all theoretically possible scenarios will significantly complicate the tools to the point where desire to implement will likely significantly diminish.

All this to say, your comment raises a great point that perhaps we should take a step back and find out the realistic combinations which WG plans to solve from OAM perspective.

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

Noted.

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

Correct, we acknowledge the scenarios which we do not support. This goes back to the point [above] of what scenarios we want to fix. We can use some help from WG to define this space.

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

Interesting point, didn't think about this one, but yes I agree, it's troublesome.

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

To trace the LSP starting from such LSR, I don't believe *stitching behavior* of the LSR is not relevant. Yes such LSR can be egress of ELC LSP, but [some] packets MAY or MAY NOT come in with ELI/EL, when ELI/EL is pushed is up to ingress to decide. If we want to diagnose the *stitching behavior* of the LSR, we will have to initiate the LSP traceroute from prior LSP.

> 
> The term "IP Based Load Balancer" is never defined.
> 
> The term "Label Based Load Balancer" is never defined.

Good point. We will add a terminology for those.

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

This one, again, goes back to the problem-space point above.

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

ACK. Until problem-space is defined, we will clarify these assumption which proposal is intended work.

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

Good point. We will rephrase above.

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

It would be a good idea to rephrase above as well, thank you for pointing this out.

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

ACK.

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

I will check with George on this, but I believe what he meant was:

   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 Nil-FEC indicating ELI, the responder must behave 
   (for load balancing purposes) as if the first word of the message 
   were a Pseudowire Control Word.

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

Sorry for newbie mistake. Any wording you can suggest?

> 
>       *  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)?

Yes, let's get consensus on problem-space first.

> 
> Nits:
> 
> s/indicate and entropy/indicate and entropy/

Thanks & ACK on s/indicate and entropy/indicate an 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".

Ok, will do.

And again, thank you for providing detailed comments!!

-Nobo

> 
> probably plenty more nits that I missed.
> 
> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 21 Jan 2014 01:52:13 -0500

In message <[email-masked]>
"Nobo Akiya (nobo)" writes:
> Assumption here is that label stack up to ELI/EL is constant for LSP
> tracing purpose, thus defined procedure will work whether transit LSR
> load balances on just (EL) or (label stack up to EL + EL). This
> assumption is most probably worth being mentioned in the document, and
> we will plan to do so.

What I meant was you don't know what an LSR will do with the label
entries below ELI/EL since RFC 6790 makes stopping the search for
further entropy a SHOULD.  An LSP carrying MPLS traffic will have
other things under the ELI/EL.

> The other tricky aspect depends on the outcome of
> draft-ravisingh-mpls-el-for-seamless-mpls. If multiple ELI/ELs are
> allowed in the label stack, and there are no clear defined forwarding
> rule on load balancing in that case, then defined procedures will not
> work, since we now have 2 (or more) non-constant values. I spoke to
> R. Singh and Y. Shen at Vancouver and communicated this concern on
> from OAM perspective.

As I understand it, the load balancing SHOULD be based on the top EL
according to RFC 6790.  OTOH it is only SHOULD.

> You are right, that is still allowed by RFC6790.

And load balance on labels plus IP was always allowed before RFC 6790.

> Adding LSP traceroute support for such will require [even more]
> complexities in the tools, which I personally would prefer to avoid if
> possible. I'd like to hear from WG on this, particularly those
> implementing ELI/EL. If there are any vendors looking at EL + IP for
> load balancing when EL is present, and if we want this scenario to
> also be supported by LSP traceroute, then we need to address this.

Do you want tools that work for some networks and not others?  If you
want tools that work for all allowed behavior then you will need some
complexity given the way the RFCs are defined.

> traffic vs. MPLS echo request?

The flag would be set in the Echo Reply and indicate which of these
behaviors the LSR will be using on the traffic.

> 2. LSP which all LSR load balances just on label stack as entropy.

Which is why I've mentioned a number of times on MPLS WG mailing list
and at meetings that the support for multipath in LSP Ping was
broken.  There are LSR that use both.

> 3. LSP which all LSR load balances on IP as entropy OR label stack as
>    entropy (assuming constant label stack + one EL).

And if that is all you cover, then LSP Ping remains broken.

> Agree that there are many load balance implementations
> possibilities. I wish there was a clear load balance rules defined
> from the beginning. I also wish there _is_ a clear load balance rules
> defined today ... is there one? Without clear defined rules, OAM is
> placed in a very difficult position: i.e. solving all theoretically
> possible scenarios will significantly complicate the tools to the
> point where desire to implement will likely significantly diminish.
>  
> All this to say, your comment raises a great point that perhaps we
> should take a step back and find out the realistic combinations which
> WG plans to solve from OAM perspective.

LSP Ping should cover all of the cases that are legal:

  IP only
  labels only
  both IP and labels

  No EL support

  EL support also using labels above ELI/EL
  EL support throwing out anything above ELI/EL, using EL only

  EL support terminating at EL
  EL support but also using labels below EL

There are quite a few combinations.  Add to this:

  only the top N labels
  up to M bottom labels for label stack of up to N labels (M < N)

  can only find IP stack if label stack <= depth of N

  hash on special labels
  special labels are skipped
  skip special labels but count toward limits

This is why some flags are needed so that the LSR can in the Echo
Reply indicate how it behaves.

Any change to RFC 4379 should document how to deal with each of the
cases as best as possible.

> Correct, we acknowledge the scenarios which we do not support. This
> goes back to the point [above] of what scenarios we want to fix. We
> can use some help from WG to define this space.

The problem here is that if one LSR uses labels only and another uses
IP only and the LSP is carrying MPLS traffic (traffic payload already
has labels) with IP under it, then the traffic exercises all paths but
the OAM just gives up.

> Interesting point, didn't think about this one, but yes I agree, it's

So the N bit does nothing useful.

> To trace the LSP starting from such LSR, I don't believe *stitching
> behavior* of the LSR is not relevant. Yes such LSR can be egress of
> ELC LSP, but [some] packets MAY or MAY NOT come in with ELI/EL, when
> ELI/EL is pushed is up to ingress to decide. If we want to diagnose
> the *stitching behavior* of the LSR, we will have to initiate the LSP
> traceroute from prior LSP.

I'm thinking of hierarchy, not stitching.  The existing ELI/EL in the
traffic is on the stack after the client LSP label.

> Good point. We will add a terminology for those.

Thanks.

> This one, again, goes back to the problem-space point above.

If that is the behavior of an LSR then LSP Ping doesn't work.  Leaving
a big hole in LSP Ping is not a good thing.

>    were a Pseudowire Control Word.

For LSR that look past the EL when TTL is incremented the data plane
will not behave that way.  The Echo Reply should indicate that this is
going to happen.

> Sorry for newbie mistake. Any wording you can suggest?

I think what you were trying to say here was:

  Note that this procedure only traces to the end of the MPLS LSP that
  is under test and will not verify the PW FEC.

Also:

  To actually verify the PW-FEC or in the case of a MS-PW, to
   determine the next pseudowire label value, the initiator MUST
   repeat that step of the trace, (i.e., repeating the TTL value used)
   but with the FEC- Stack modified to contain the appropriate PW-FEC.

I don't think this (the whole procedure in this paragraph actually
works for LSR that use the whole label stack up to the EL (or fat PW
label).  For fat PW the PW and flow label will both be used.  You need
to put the PW label in the stack.  That is where the VCCV CW comes in
handy, allowing the OAM IP payload to be carried but not treated as
IP.  This CW usage (or GAL) can be carried into LSP Ping.

> Yes, let's get consensus on problem-space first.

In the past I've advocated either fixing or depricating LSP Ping
multipath support.

> Thanks & ACK on s/indicate and entropy/indicate an entropy/

oops

> And again, thank you for providing detailed comments!!

Thanks,

Curtis

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Wed, 22 Jan 2014 22:00:15 +0000

Hi Curtis,

Thanks again for detailed comments!

Point is well taken for additional cases.

For the load balancing cases you've listed, there are two cases of each when considering stitched/hierarchical LSP.

1. LSRs which load balances on the cases you mentioned and forwards the packet.
2. LSRs which load balances on the cases you mentioned, pushes EL and forwards the packet.

MPLS echo reply will need to differentiate both cases, mapping carried in case of (2).

Today, despite large number of cases already existing, LSP ping/trace multipath capability remains to be functional and used by many operators. Introduction of EL will break these "working cases", and my current focus on this draft will continue to be addressing the "working cases" when EL is in the picture.

With that said, having tools (whether LSP ping/trace multipath or otherwise) to deterministically discover and exercise MPLS ECMP for all cases of MPLS load balancing is a goal which I highly support. I'd like to suggest taking this up as a separate effort outside of this draft. If WG consensus is to use this draft as a vehicle to do so, then I'm willing to contribute.

As result of your comments (thank you for them!), I plan to make following change in the next revision.

1. Add a section describing the cases which LSP ping/trace multipath worked, got broken with EL and being addressed by this draft.
2. Add terminology section.
3. Mention RFC6424 in introduction when RFC4379 is mentioned.
4. Fix the paragraph describing EL-FEC/NIL-FEC.
5. Replace "transport layer" to text you suggested.
6. s/indicate and entropy/indicate an entropy/
7. Sec 5.2 third bullet, split into sub-bullets. Same treatment to similar.

-Nobo

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Tuesday, January 21, 2014 1:52 AM
> To: Nobo Akiya (nobo)
> Cc: [email-masked]; Loa Andersson; Sriganesh Kini; Xuxiaohu; Curtis
> Villamizar; Daniel King; [email-masked]; draft-akiya-mpls-
> [email-masked]; [email-masked]
> 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
> 
> 
> > > 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).
> >
> What I meant was you don't know what an LSR will do with the label entries
> below ELI/EL since RFC 6790 makes stopping the search for further entropy
> a SHOULD.  An LSP carrying MPLS traffic will have other things under the
> ELI/EL.
> 
> > work, since we now have 2 (or more) non-constant values. I spoke to R.
> > Singh and Y. Shen at Vancouver and communicated this concern on from
> > OAM perspective.
> 
> > > 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.
> >
> and at meetings that the support for multipath in LSP Ping was broken.
> There are LSR that use both.
> 
> > Agree that there are many load balance implementations possibilities.
> > I wish there was a clear load balance rules defined from the
> > beginning. I also wish there _is_ a clear load balance rules defined
> > today ... is there one? Without clear defined rules, OAM is placed in
> > a very difficult position: i.e. solving all theoretically possible
> > scenarios will significantly complicate the tools to the point where
> > desire to implement will likely significantly diminish.
> >
> This is why some flags are needed so that the LSR can in the Echo Reply
> indicate how it behaves.
> 
> > > 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.
> >
> > Noted.
> >
> > >
> > > 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.
> > >
> > > E=0 that existing in RFC 4379 prior to ELI/EL) but doesn't fix them
> > > even though they are fixable:
> > >
> The problem here is that if one LSR uses labels only and another uses IP
> only and the LSP is carrying MPLS traffic (traffic payload already has labels)
> with IP under it, then the traffic exercises all paths but the OAM just gives
> up.
> 
> > > 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.
> >
> > > 4379 where the behavior was undefined both in terms of what to put
> > > in the reply and how the initiator should interpret it.
> > >
> > > 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.
> >
> I'm thinking of hierarchy, not stitching.  The existing ELI/EL in the traffic is
> on the stack after the client LSP label.
> 
> > > 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.
> >
> If that is the behavior of an LSR then LSP Ping doesn't work.  Leaving a big
> hole in LSP Ping is not a good thing.
> 
> > > 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".
> >
> > > A lot of equipment uses all of the labels.  Did you means does not
> > > use the bottom label?
> >
> > > 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?
> >
> > > 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.
> >
> For LSR that look past the EL when TTL is incremented the data plane will
> not behave that way.  The Echo Reply should indicate that this is going to
> happen.
> 
> > > That is not what "transport layer" means to a lot of people.  Very
> > > bad wording.
> >
> I don't think this (the whole procedure in this paragraph actually works for
> LSR that use the whole label stack up to the EL (or fat PW label).  For fat PW
> the PW and flow label will both be used.  You need to put the PW label in
> the stack.  That is where the VCCV CW comes in handy, allowing the OAM IP
> payload to be carried but not treated as IP.  This CW usage (or GAL) can be
> carried into LSP Ping.
> 
> > > 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
> In the past I've advocated either fixing or depricating LSP Ping multipath
> support.
> 
> > > Nits:
> > >
> > > 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".
> >
> > Ok, will do.
> >

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 24 Jan 2014 02:15:14 +0000

Hello authors,

The draft is reasonably coherent. It addresses a useful problem.
Technically it is a start. The document is ready to be considered for WG
adoption.

A few comments -

1. sec 8. DSMAP is deprecated. Should be removed. Even though "Multipath
Info" field was in DSMAP too, since a more recent RFC has deprecated it,
it should no longer be used. Some implementations referring to DSMAP is
not a reason to continue using if the intention is to get to a proposed
standard. 

2. The notation {x, y, z} is introduced in section 2, without mentioning
what it means. I am assuming it means one-of. Should be stated clearly.

3. sec 9 bullet 1 - If the transit node encounters a deep label stack, it
may not be able to access labels till the bottom of stack to compute the
hash. If this is the case, "Depth Limit" should take care of this. It is
not clear what this unsupported-case is and why it should occur.

4. sec 9. bullet 2 - Is this case when the transit node is using other
labels in the label stack "in addition to the EL" OR is it when the
transit node is using a non-EL label in the stack even if EL is included ?
The former case is typical. The latter case I would imagine can occur if
the transit LSR cannot access the entire label stack depth. Again not
clear what the unsupported case is.

5. Does the draft make a distinction between the two cases allowed by
RFC6790, namely -

    a. Load balance solely on the EL

    b. Use as-much of the label-stack as feasible

6. The "Associated Label Multipath Information" field should be better
explained. I would suggest a separate section to improve the coherency.

Thanks

Sri

On 1/3/14 12:22 AM, "Loa Andersson" <[email-masked]> wrote:

>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]
>Senior MPLS Expert                          [email-masked]
>Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Fri, 24 Jan 2014 23:31:20 +0000

Hi Sri,

Thank you for comments.

> Info" field was in DSMAP too, since a more recent RFC has deprecated it, it
> should no longer be used. Some implementations referring to DSMAP is not
> a reason to continue using if the intention is to get to a proposed standard.

I see. I will speak to few people and if this is indeed the case, I will remove DSMAP from document (either next revision or later revision).

> 
> 2. The notation {x, y, z} is introduced in section 2, without mentioning what
> it means. I am assuming it means one-of. Should be stated clearly.

Good point. I will add a description on this notion.

> 
> 3. sec 9 bullet 1 - If the transit node encounters a deep label stack, it may
> not be able to access labels till the bottom of stack to compute the hash. If
> this is the case, "Depth Limit" should take care of this. It is not clear what
> this unsupported-case is and why it should occur.

Yes "Depth Limit" can communicate something. One question is, is this top N labels or bottom M labels? Either way, if Flow Label or Entropy Label is not included in this "Depth Limit", then initiator LSP cannot make changes to the label stack to traverse all ECMP paths at this point.

> 
> 4. sec 9. bullet 2 - Is this case when the transit node is using other labels in
> the label stack "in addition to the EL" OR is it when the transit node is using
> a non-EL label in the stack even if EL is included ?
> The former case is typical. The latter case I would imagine can occur if the
> transit LSR cannot access the entire label stack depth. Again not clear what
> the unsupported case is.

I will rewrite this entire section on what is and isn't supported. Hopefully next revision will be more clearer.

>     b. Use as-much of the label-stack as feasible

This will be covered with section 9 rewrite.

> explained. I would suggest a separate section to improve the coherency.

I believe this is well described in section 8. Please let me know if you think it is still insufficient.

Thanks again!

-Nobo

> >This was the wrong document - I intended to have the review done for
> >draft-akiya-mpls-entropy-lsp-ping sorry for the confusion.
> >
> >> 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.
> >>
> >> 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
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls