Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>
David Allan I writes:
> 
> Hi:
>  
> I was asked to review this document as part of the review team; the
> following are my comments.
>  
> I think such a document in general has merit and addresses a gap. I
> believe the issues that exist with this particular version of such a
> document are in the incomplete discussion of a solution in section
> 3. I'd want to see that cleaned up such that it read as a technically
> viable solution....(see below)....

Dave,

If it is unclear to you, then the document is not sufficiently clear
and needs fixing.  See below.

> Nit:
>  
> Section 1 para 2: Refers to MPLS-TP packet ordering as the
> constraint. I'm a bit confused by this, any aggregate that shares an
> ordering constraint does not get spread across parallel links while a
> set of traffic COULD be in theory load spread across a set of MPLS-TP
> paths so long as individual ordering constraints were respected. Is
> this text document really discussing midbox spreading out of load that
> respects ordering constraints but would mean MPLS-TP OAM no longer
> fate shared?  Should be reworded if so. Clarified otherwise.

Section 1 paragraph 2 contains:

   RFC 5654 requirement 33 requires the capability to carry a client
   MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer
   [RFC5654].  This is possible in all cases with one exception.  When
   an MPLS LSP exceeds the capacity of any single component link it
   may be carried by a network using multipath techniques, but may not
   be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity
   limitation imposed by MPLS-TP OAM packet ordering constraints.

The sentence in question is:

   When an MPLS LSP exceeds the capacity of any single component link
   it may be carried by a network using multipath techniques, but may
   not be carried by an MPLS-TP LSP due to the inherent MPLS-TP
   capacity limitation imposed by MPLS-TP OAM packet ordering
   constraints.

Perhaps I could clarify this by changing "carried by an MPLS-TP LSP"
to "carried by a single MPLS-TP LSP".

The "MPLS-TP OAM packet ordering constraints" is the "fate sharing"
which is the reason that MPLS-TP prohibits using ECMP (aka multipath,
though ECMP is only one form of multipath) with MPLS-TP.  This is why
an MPLS LSP (client layer) with capacity greater than a component link
cannot be carried over a *single* MPLS-TP LSP.

Since this is explained in later sections I could make the
substitution suggested above or I could drop the last sentence and
mention that limitation later.

> Main issue:
>  
> Section 3: I think this needs a bit of work, it starts to discuss
> tractable solutions but IMO is technically incomplete. IF an entropy
> label and ELI (where all traffic associated with the MPLS_TP LSP
> shares a common randomly selected entropy label value, which is not
> stated) are the only mechanisms of ensuring proper treatment (with all
> transit nodes implementing entropy and ELI processing such that
> seeking sources of entropy is capped for such LSPs), and the ingress
> node (which by some means SHOULD be able to know it is a TP LSP as it
> has layer visibility) and the egress node can strip entropy and ELI
> then a solution exists for proper fate sharing and ordering of a TP
> LSP over MPLS. It is IMO not quiet eluciated completely.

Your paragraph above describes the solution, but then says "It is IMO
not quiet eluciated completely."

So lets parse your paragraph and see what the draft is missing:

> Section 3: I think this needs a bit of work, it starts to discuss
> tractable solutions but IMO is technically incomplete.

    OK ...

> IF an entropy label and ELI (where all traffic associated with the
> MPLS_TP LSP shares a common randomly selected entropy label value,
> which is not stated)

    You mention "IF an entropy label and ELI (where all traffic
    associated with the MPLS_TP LSP shares a common randomly selected
    entropy label value, which is not stated)".  Regarding the "which
    is not stated" part of that phrase I can change the following
    paragraph:

      OLD:

        MPLS-TP LSP can be carried as client LSP within an MPLS server
	LSP if an Entropy Label Indicator (ELI) and entropy label (EL)
	is added after the server layer LSP label(s) in the label
	stack, just above the MPLS-TP LSP label entry [RFC6790].
	[...]

      NEW:

        MPLS-TP LSP can be carried as client LSP within an MPLS server
        LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL)
        is added after the server layer LSP label(s) in the label
        stack, just above the MPLS-TP LSP label entry [RFC6790].  The
        value of EL can be randomly selected at LSP setup time and the
        same EL value used for all packets of the MPLS-TP LSP.  [...]

    One sentence is added to the end.  (and Entropy Label is capitalized).

> are the only mechanisms of ensuring proper treatment

    Actually link-bundling is mentioned as another mechanism.

> (with all transit nodes implementing entropy and ELI processing such
> that seeking sources of entropy is capped for such LSPs),

    The requirement to terminate search for additional entropy below
    the EL is a requirement of RFC 6790.  The intent is to say that
    non-compliant midpoint LSR would in this case cause packet order
    problems where in MPLS only (no TP carried) use of RFC 6790, those
    non-compliant midpoint LSR are tolerable as long as they can get
    enough entropy from the traffic to adequately load split.

> and the ingress node (which by some means SHOULD be able to know it
> is a TP LSP as it has layer visibility)

    That is discussed in the following paragraph:

       There is currently no signaling mechanism defined to support
       requirement MP#1.  In the absense of a signaling extension,
       MPLS-TP can be identified through some form of configuration,
       such as configuration which provides an MPLS-TP compatible
       server layer to all LSP arriving on a specific interface or
       originating from a specific set of ingress LSR.  Alternately an
       MPLS-TP LSP can be created with and Entropy Label Indicator
       (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790].

    Obviously the EL can be added at the MPLS-TP ingress LSR.  This
    paragraph is considering the case where a set of MPLS-TP LSR are
    not EL capable but also do not have multipath enabled, but
    multipath is enabled elsewhere (ie: the core where lots of traffic
    needs to get aggregated into a smaller number of LSP).  The lack
    of a signaling extension is noted as a (fixable) limitation.  The
    fix comes in a later draft (draft-villamizar-mpls-multipath-extn).

> and the egress node can strip entropy and ELI

    That is a hard requirement of RFC 6790 for an LSR claiming to
    support RFC 6790.

> then a solution exists for proper fate sharing and ordering of a TP
> LSP over MPLS.

     OK ... agreed.

> It is IMO not quiet eluciated completely.

     You seem to have figured out all of the details.

If there are additional clarifications that are needed besides the
ones suggested above, please point out what details of the solution
are still not clear in the existing text.

> If I'm unclear on any of the above, am happy to discuss...

Thanks.  Please let me know if the above clarifications are sufficient
or whether additional clarifications are needed.

> Cheers
> Dave

Cheers,
Curtis


btw - s/I-D.ietf-mpls-entropy-label/RFC6790/g

I didn't think it was worth reving the doc for that one change but I
do know about it.