[mpls] John Scudder's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this document. I agree with Éric Vyncke that the paragraph in the
introduction about moving to Historic is unusual, to say the least. However, if
the working group has consensus to publish the document in this form, I won’t
stand in their way.

I do have three points I'd like to discuss, and also a comment.

## DISCUSS

### Section 3, same values, or different?

   The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
   FLI MUST use the same values of the label immediately preceding the
   XL.  In this case the TC and TTL for the XL and FLI MAY be of
   different values.

The "in this case" sentence doesn't make sense to me (what case is "this
case"?), and seems to contradict the preceding sentence. Either they MUST use
the same values, or not. Which is it? Is there something missing before the "in
this case" sentence?

### Number of flows vs. ECMP

Section 3 says,

   The Flow-ID Label (FL) is used as an MPLS flow identification
   [RFC8372].  Its value MUST be unique within the administrative
   domain.

So, there can be at most 2^20 flows per administrative domain. That seems
small, but I guess it's OK if I think of the number of instrumented flows as
being a small fraction of the total flows that exist. But then later, Section 7
says,

   Analogous to what's described in Section 5 of [RFC8957], under
   conditions of Equal-Cost Multipath (ECMP), the introduction of the FL
   may lead to the same problem as caused by the Synonymous Flow Label
   (SFL).  The two solutions proposed for SFL would also apply here.
   Specifically, adding FL to an existing flow may cause that flow to
   take a different path.  If the operator expects to resolve this
   problem, they can choose to apply entropy labels [RFC6790] **or add FL
   to all flows**.

(Emphasis added.)

When I add these up, it seems to me that the operator of a large network has
some unpleasant options.

- They can accept that the use of FL may perturb the path taken by the flow.
But that seems unacceptable for a technology whose purpose is performance
measurement.

- They can use entropy label.

- They can add FL to all flows, but this means they have to instrument every
flow, so they really are restricted to 2^20 total flows in their network. That
is a rather small number, probably too small for a significant deployment.

The conclusion I arrive at is that any deployment at scale has to use entropy
label. Is that correct? If so it seems to me it would be better to be more
up-front about it. If I'm mistaken (e.g. there's some realistic use case where
it's fine to accept the observer effect perturbing the selected path, or where
2^20 flows is more than enough) I'd appreciate some help seeing it.

### Penultimate hop popping creates a conflict

Section 4 has,

   *  The processing node MUST pop the XL, FLI and FL from the MPLS
      label stack when it needs to pop the preceding forwarding label.
      The egress node MUST pop the whole MPLS label stack, and this
      document doesn't introduce any new process to the decapsulated
      packet.

But Section 3.1 said,

   Note that here if the penultimate hop popping (PHP) is in use, the
   PHP LSR that recognizes the cSPL MUST NOT pop the cSPL and the
   following Flow-ID label, otherwise the egress LSR would be excluded
   from the performance measurement.

As far as I can tell, these two are in conflict, and there's no way to comply
with both other than by disabling PHP. That's OK I guess, but if so you should
just say PHP isn't allowed.

By the way (and this is not DISCUSS level, just included here since we're
already talking about this section) I find it problematic that a subsection
called "examples" includes normative requirements, which 3.1 does in two places
-- the quote above, and also,

   Note that for this example, the two Flow-ID Label values appearing in
   a label stack MUST be different.  In other words, the Flow-ID label
   applied to the MPLS transport and the Flow-ID label applied to the
   MPLS service MUST be different.  Also, note that the two Flow-ID
   label values are independent of each other.  For example, two packets
   can belong to the same VPN flow but different LSP flows, or two
   packets can belong to different VPN flows but the same LSP flow.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

### Section 8, ACLs

The Shepherd write-up, and Section 9, indicate that this specification has been
implemented. Section 8 says,

   To prevent packets carrying Flow-ID labels from leaking from one
   domain to another, domain boundary nodes SHOULD deploy policies
   (e.g., ACL) to filter out these packets.  Specifically, at the
   sending edge, the domain boundary node SHOULD filter out the packets
   that carry the Flow-ID Label Indicator and are sent to other domains.
   At the receiving edge, the domain boundary node SHOULD drop the
   packets that carry the Flow-ID Label Indicator and are from other
   domains.

Do the existing implementations provide the necessary ACL primitives to comply
with the SHOULD above? For that matter, why are these SHOULD and not MUST?