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

[Éric Vyncke via Datatracker <[e-mail]>]

É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.