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

[Tony Li <[e-mail]>]

Hi Éric,

I would like to respond to your non-technical point.  I will leave it to the authors to respond to your other issues.

Work on this draft predates the work on MNA by quite a bit. It has found interest with vendors and operators and has had multiple implementations that are now deployed in production. The proponents of the draft have correctly asked that we progress the draft as the work on the technology has converged. This is exactly what the IETF is supposed to do: standardize running code.

Work on MNA is still progressing, and no replacement for this functionality is currently documented, but it is quite clear that MNA is the direction that we would like to go in the longer term. After long discussions with all parties involved, we came to this agreement and recording it in the RFC itself seemed like the most appropriate mechanism to ensure that the agreement was on record and that the industry was aware of the direction that we are taking. This allows vendors and operators to plan accordingly. Technology evolves over time and it is helpful to the industry as a whole if we provide leadership and insight into future directions.

While I understand that this is an unusual situation, we are trying to ensure that we respect the interests of the IETF as a whole, vendors, and operators in this matter and craft a compromise that best suits all involved, both in the present and the future. This decision was not taken lightly but came about after extensive negotiations. We would respectfully ask that you not characterize this in terms that are suggestive of terrorism.

I apologize that there was not an adequate discussion of this in the shepherd’s writeup.

Regards,
Tony Li
MPLS co-chair


> On Aug 30, 2024, at 4:57 AM, Éric Vyncke via Datatracker - noreply at ietf.org <[e-mail]> wrote:
> 
> É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.
> 
> ## 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.
> 
> ## 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 ?
> 
> 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 ?
> 
> ## 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' ?
> 
> 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 ?
> 
> ## Section 7
> 
> Please add a reference for `Synonymous Flow Label`.
> 
> ## 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 ?
> 
> # NITS (non-blocking / cosmetic)
> 
> ## Section 3
> 
> Rather than `as shown in figure below` please use the figure number.
> 
> 
>