[mpls] Re: Deb Cooley's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

[[e-mail]]

Hi Deb,

Thanks for your review and comments.
Please see inline.


Original


From: DebCooleyviaDatatracker <[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月03日 01:20
Subject: Deb Cooley's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)


Deb Cooley has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: No Objection
 
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:
----------------------------------------------------------------------
 
Note:  routing and MPLS are not my strong suit. And while the Introduction
looks a little unusual, Tony Li's explanation on the list makes sense (to this
'not a routing' person).
 
I have one comment:
 
Section 8, paragraph 1:  Like Eric V., I also don't see the security
consideration in this paragraph.  I would ask why 'the value of a Flow-ID label
MUST be unique within the administrative domain'?  What result does a collision
in the labels cause?
 [XM]>>> The network nodes would report the counters and timestamps along with the Flow-ID, and the controller would calculate the packet loss and delay per Flow-ID. So, if there is a collision in the labels, then the calculation would be wrong.

Best Regards,
Xiao Min