[mpls] Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

[[e-mail]]

Hi Eric,

Thanks for your thoughtful review and comments.
Please see inline.

Original


From: ÉricVynckeviaDatatracker <[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年08月30日 19:57
Subject: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: Abstain
 
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/
 
 
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
 
# Éric Vyncke, INT AD, comments for draft-ietf-mpls-inband-pm-encapsulation-15
 
Thank you for the work put into this document. As this I-D is about very
specific protocols, I have only reviewed it from the high level perspective.
 
I am balloting ABSTAIN because I am neither comfortable nor confident that
having a time bomb (see below about MNA) in a published RFC is sensible.
 
Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.
 
Special thanks to Tony Li for the shepherd's write-up even if more information
about the 'time bomb' would have assisted my reading.
 
I hope that this review helps to improve the document,
 
Regards,
 
-éric
 
# COMMENTS (non-blocking)
 
## Having the time bomb...
 
Both the shepherd's write-up and section 1 `it is agreed that this document
will be made Historic` contain a trigger bomb to make this document historic.
No explanations are given, so I guess that this was a WG compromise but without
any further justification, it is hard to tell and hard to judge the IETF
consensus.
 
Why has the MPLS WG (and IETF Last Call and then the IESG) worked on this
document if it was clear that it will become historic ?
 
I am not convinced that `it is agreed` in an IETF RFC is meaningful.
 
If the authors or the MPLS WG have a precedent case in a published RFC, then I
will be happy to read it.
 [XM]>>> I noticed Tony Li has replied to this point. That's exactly what happened and no more words from my side.


## Section 2.1
 
Beyond acronyms expansions, some information references (e.g., for IPFIX or
MNA), or some concise definitions (e.g., for eSPL or cSPL) would be useful for
the readers.
 [XM]>>> Make sense. Propose to make the changes as below.
IPFIX, add a reference to RFC7011.
MNA, add a reference to RFC9613.
eSPL, add text "A special-purpose label that is placed in the label stack after the Extension Label (value 15)".
cSPL, add text "The combination of the Extension Label (value 15) and an Extended Special Purpose Label".


## Section 3
 
Possibly linked to my lack of MPLS expertise, I wonder why fields MUST be
identical and MAY differ in `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. ` Should `In this case` be more specific ?
 [XM]>>> "In this case..." should have been deleted along with the deletion of "unless..." in version -15. That's a missing point when I made changes in version -15. Will delete "In this case..." in version -16. Sorry for the confusion.


What is the expected behavior when the TC/TTL are not using the same value ? Is
this specified in other MPLS document or should it be specified in this I-D ?
 [XM]>>> The quoted text was originally borrowed from Section 4.2 of RFC 6790, which says "X SHOULD put the same TTL and TC fields for the ELI as it does for TL". Considering the exception case in RFC 6790 doesn't apply to this document, MUST is used rather than SHOULD. In RFC 6790 I don't find the expected behavior when the TC/TTL are not using the same value, so propose to remain as is.


## Section 4
 
Also probably due to my own lack of expertise, how can a transit MPLS node know
that it needs to do 'deep packet inspection' ?
 [XM]>>> That may be the default behavior of a transit MPLS node or some provision may be needed. It seems to me it's outside the scope of this document. 


BTW, as 'deep packet inspection' is usually used in a security context to look
in the application payload, may I suggest to use 'labels look-ahead' or
something similar ?
 [XM]>>> Is s/deep packet inspection/deep labels inspection ok for you?


## Section 7
 
Please add a reference for `Synonymous Flow Label`.
 [XM]>>> There is already a reference to RFC 8957 (Synonymous Flow Label Framework). I don't mind to add one more reference to that RFC. :-)


## Section 8
 
While I understand that it is not clean when packets with those labels leak
outside the admin domain, what are the *actual security issues* ? E.g., DoS ?
privacy ?
 [XM]>>> To be honest, I don't see *actual security issues* here. If there are some, I'm happy to add. The Flow-ID label introduced in this document is similar to the Entropy label introduced in RFC 6790, and after checking the security section of that RFC, I don't find them.


# NITS (non-blocking / cosmetic)
 
## Section 3
 
Rather than `as shown in figure below` please use the figure number.
 [XM]>>> OK. Will do that change.
 




Cheers,
Xiao Min