Re: [mpls] MPLS-RT review of draft-bryant-mpls-sfl-framework

[Curtis Villamizar <[e-mail]>]

Loa,

The document is coherent and possibly useful.  The question of IPR
should be resolved before accepting this as a WG document.

Briefly:

  1.  The document proposes a change to forwarding.  Whenever a change
      in forwarding is considered, there should be a very substantial
      benefit and interoperability with older hardware should be
      considered in the document.

  2.  The document leaves open the question of dealing with ECMP in
      section 4.  The first option in section 4 is not viable.  The
      document should drop this and expand on the second "worthy of
      consideration" solution, explaining how it will work in the same
      level of detail as provided in 3.1, 3.2, and 3.3.

  3.  In the VPN example a perceived advantage of MP2P LSP is lost.
      With MP2P LSP, the number of application labels needed is the
      number of VPN IDs.  The number of labels needed becomes number
      of VPN IDs times the number in ingress.  If Section 3.3 is
      supposed to address this, then this is not clear and therefore
      could benefit by referring back to the example and stating that
      the SFL could indicate source only and the application label
      indicate VPN ID only.

More detail:

Forwarding of labeled packets currently involves some special
processing of labels 0-15 and some form of lookup in a table or TCAM
or other structure with the lookup resolving to a set of operations.
At mimimum these operation are SWAP and forward to an egress
optionally after considering ECMP (EL or rest of stack), POP and look
at next label (or assume IP payload if no next label).  Forwarding
hardware currently need not support a POP and look for IP payload.
That operation is only required of the IPv4 Explicit NULL Label and
IPv6 Explicit NULL Label.  Second, both Explicit NULL labels in
RFC3032 are required to be at the bottom of stack in RFC3032 with this
restriction removed in RFC4182 for proper operation of the pipe model
when not using an ordinary label POP at egress.

The changes to forwarding are:

  1.  Processing of an ordinary label (label not in the 0-15 range)
      must be able to POP and look at the IPv4 or IPv6 payload to
      conform to section 3.2 of this draft.  Currently this processing
      can be fixed to label values 0 and 2 respectively.

  2.  Processing of an ordinary label taking on the function of an
      explicit NULL and processing of an explicit NULL label must be
      capable of handling ELI and EL below the SFL or Explicit NULL
      and then take the same action as would be taken for Explicit
      NULL after the ELI and EL POP.  This would be needed to support
      pipe model as described in RFC4182 and not change the
      penultimate LSR to SWAP a lable for SFL or Explicit NULL and
      remove ELI and EL from underneath.

I'm assuming that SFL would not map to special labels other than
Explicit NULL but such a statement should be made explicit.  Although
if applied to RFC 6374 then SFL might also map to GAL.  If SFL can map
to other special labels, then those others from the set of 0-15
including mapping to ESPL should be mentioned.  Each time a new
special label is defined there are complaints about changing
forwarding.  If now any ordinary label can map to a specific set of
special labels, or worse to any special label, then this is a
substantial change in the definition of MPLS forwarding.

btw- In practice the IPv6 Explicit NULL is rarely if ever used but
instead POP of an ordinary label at BOS, label zero (IPv4 Explicit
NULL) at BOS, or lack of a label stack after PHP looks for the IP
version in the payload.  Does any RFC say to do this (combine the
meaning of IPv4 Explicit NULL and IPv6 Explicit NULL and look at IP
version in the payload) or is this just common practice for almost 20
years that escaped getting documented?

The second issue relates to ECMP.  Section 4.1 item 1 suggests that
"The operator can elect to always run with the SFL in place".  If the
value of SFL is different for data traffic and PM traffic, then the PM
would not take the same path.  This would put each "flow" in a
multipoint to point LSP (ie: LDP) on a separate path which for ECMP is
not an issue.

If the only purpose of the SFL was maintain separately counters for
specific multipoint to point LSP ingress then lack of SFL for other
ingress has no effect.  In this case the "solution" described in
Section 4.1 item 1 is a NOOP.

If the purpose is to also provide separate PM for specific (or all)
multipoint to point LSP ingress or provide separate counters for PM
for a point to point LSP, then the "solution" described in Section 4.1
item 1 fails.

Section 4.1 item 1 therefore needs to be removed.

The implications of Section 4.1 item 2 need to be better explored.
The section as-is constitutes a "punt" on the problem of ECMP with SFL
used for PM.  A diagram of each case in Section 3 with ELI and EL can
be added in Section 4 or the optional placement of ELI and EL.  The
behaviour when ELI and EL are present can then be described in Section
4 with penultimate LSR behaviour in addition to egress LSR behaviour
described for both PHP and non-PHP case.

Nits:

In "Abstract" the phrase "on the on the" should be "on the".

In Section 2 "defined to be a label" is awkward.

An alternate:

An alternate to the proposal here would be to make something like what
is in Section 3.3 the only case, but where a ESPL range is used.  This
would add egress processing without stepping on ECMP since SPL and
ESPL are excluded from ECMP according to RFC 7274.  An ESPL with a few
top bits always set and less than 20 bits of range could be considered
(for example XL + 1111xxxxxxxxxxxxxxxx for 16 bits of range and 1/16
of the ESPL space in RFC 7274).  This range would be defined such that
it is application specific, is added at ingress, completely ingnored
along the way and provides the some egress specific functionality.
Most implementations that support RFC 6790 are likely to also support
the prohibition on using ESPL for ECMP since the documents were in the
MPLS WG at about the same time, though publication of the latter
lagged about a year.  This alternative also solves any scalability
problem associated with combining source and application label
functionality into one label.  It does add two labels to the stack
depth but newer hardware should no longer be constrained to very
shallow stack depth.  This alternate also might be an even more
attractive option if IPR becomes an issue with the current proposal.

Summary:

well written document.  not a great design.  multiple problems as
defined.  possible IPR issue.

consider alternative.  any alternative but I provided one.  feel free
to use the idea.  :-)

Curtis


In message <[e-mail]>
Loa Andersson writes:
> 
> Huub, Andy, Curtis and Kamran,
>  
> You have been selected as MPLS-RT reviewers for 
> draft-bryant-mpls-sfl-framework-04
> .
>  
[ ...]