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

[[e-mail]]

Hi Eric,

A new version -16 of this document has been posted to address your comments. Link as below.
https://datatracker.ietf.org/doc/html/draft-ietf-mpls-inband-pm-encapsulation-16

Best Regards,
Xiao Min

Original


From: 肖敏10093570
To: EricVyncke(evyncke) <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Tarek Saad (tsaad) <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月03日 14:36
Subject: Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)



Hi Eric,

Thank you for the confirmation and suggested new text.
I'll make the changes we agreed to version -16.
With respect to the security considerations, I agree to add the text you proposed as "packet leakage is neither breaching privacy nor can be a source of DoS".

Cheers,
Xiao Min






From: EricVyncke(evyncke) <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;Tarek Saad (tsaad) <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2024年09月02日 20:31
Subject: Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)



Hello Xiao and Tony,
 
While I am still puzzled by the ‘time bomb’ in an RFC, all the suggested changes look like improvements (including the use of “deep labels inspection”).
 
About the security considerations, we agree it seems ;-) but this may also be added in the text “packet leakage are neither breaching privacy not can be a source of DoS” (even if we can argue that such packets could increase the CPU utilization of another admin domain).
 
Regards
 
-éric
 


From: [e-mail] <[e-mail]>
 Date: Monday, 2 September 2024 at 11:43
 To: Eric Vyncke (evyncke) <[e-mail]>
 Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Tarek Saad (tsaad) <[e-mail]>, [e-mail] <[e-mail]>
 Subject: Re: Éric Vyncke's Abstain on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)



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