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

[[e-mail]]

Hi Roman,
Thanks for your review and comments.
Please see inline.

Original


From: RomanDanyliwviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月04日 00:04
Subject: Roman Danyliw's Discuss on draft-ietf-mpls-inband-pm-encapsulation-15: (with DISCUSS and COMMENT)

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?
 [XM]>>> I understand your concern. Bullet (c) and (d) are used to elaborate (b), and they are dual fail-safe. As I've responded to John Scudder, the three "SHOULD" will be replaced by "MUST" in the next revision. Does that change resolve your DISCUSS?
 
----------------------------------------------------------------------
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?
 [XM]>>> Is deleting "However,..." ok for you?
 




Best Regards,
Xiao Min