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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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:
----------------------------------------------------------------------

** Section 8.

There appears be conflicting guidance on how to handle packets on the
administrative domain boundary.

   (a) The Flow-ID
   label MUST NOT be signaled and distributed outside the administrative
   domain.

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

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

   (d) At the receiving edge, the domain boundary node SHOULD drop the
   packets that carry the Flow-ID Label Indicator and are from other
   domains.

Why is the SHOULD in (b), (c) and (d) not a MUST?

If (a) mandates that there is no signaling of the Flow-ID outside of the
administrative domain, (b) and (c) should be mandatory to enforce that policy.

If (d) uses a weaker “SHOULD”, what would the receiving edge do with the packet
if not drop it?


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

** For the responsible AD and WG chairs: I observe that this document doesn’t
fit neatly into the work items described in the “The current WG focus areas and
work items” section of https://datatracker.ietf.org/doc/charter-ietf-mpls/07/

** Section 6.
   How the ingress node knows the FLC and FRLD of all
   the on-path nodes is outside the scope of this document.  However,
   [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

Why make a reference to an expired, individual submission if the methodology is
out of scope?