Re: [mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-rfc6374-sfl-09: (with DISCUSS and COMMENT)

[Stewart Bryant <[e-mail]>]

> On 25 Feb 2021, at 09:14, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-mpls-rfc6374-sfl-09: Discuss
> 
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sfl/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> There may be a couple of internal (or external?) inconsistencies
> lingering, and while my confidence level of that is not as high as it
> often is, it's probably still worth checking.

> Specifics in the COMMENT, but at a high level, do we use ACH value
> 0x000A (what's shown in Section 9) or the TBD IANA-allocated values

When we originally proposed this we were only going to use one measurement type (type 0xA). We should have updated this text to point to both the existing additional methods and the new methods that we created during the course of this work.

I toyed with generalising the section, but in the I decided that the best way to great a simple explanation of the protocol would be as follows:

At the start of the section I changed the text to:

"We illustrate the packet format of an RFC6374 Query message using SFLs
for the case of an MPLS direct loss measurement in
{{Figure1}}.”

And then at the end of the section I added the following text:

"Where a measurement other than an MPLS direct loss measurement is to be
made, the appropriate RFC6374 measuremnet message is used (for example, one of the
new types defined in this document) and this is indicated to the receiver
by the use of the corresponding ACH type.



> ; we
> seem to refer to RFC 6374 as providing some things that I can't find in
> it; and the IANA considerations registration request includes a "TLV
> follows" column that does not appear to be present in the registry (and
> does not appear to match the described behavior in the rest of the
> document).  

We deprecated ACH TLV with RFC7026 as we could find no use for them and they complicated the handover from the forwarder to the OAM handler, This was not originally a problem as we were only doing connectivity measurement, but with the new fast OAMs such as the packet delay measurement methods the this was an issue. As we had never defined an ACH TLV deprecating them was easy.

This is of course distinct from RFC 6374 TLVs which we deal with in the RFC 6374 handler.

> Perhaps this (the current registry state) is the result of
> RFC 7026's actions, but I'm not entirely sure.
> 

I will deal with the comments in a separate email.

If this addresses your content, can I request that you clear your discuss on the basis of the version of the draft I am about to upload?

The comments will of course be addressed to the satisfaction of the new responsible AD, though I will of course try to get them fixed before Deborah steps down on Wednesday.

Many thanks for your review and for catching this issue.

Best regards

Stewart