Subject: [ippm] Comments on draft-fear-ippm-mpdm-00

From: "C. M. Heard" <[email-masked]>
Date: Sat, 2 Jun 2018 10:54:48 -0700

Greetings,

I briefly perused https://tools.ietf.org/html/draft-fear-ippm-mpdm-00, and
I have a few preliminary comments.

   1. The M-PDM destination option layout and contents are very similar to
   those of the PDM option defined in RFC 8250, and initially I didn't grasp
   what additional purpose it serves. The explanation does not come until
   Section 5 where the Marking field is finally discussed. You would be doing
   your readers a huge favor to put the background discussion (and reference
   to RFC 8231) right up front. That is still recommended even if you accept
   the next comment.
   2. As far as I was able to determine, the only real purpose of defining
   the M-PDM destination option is to have a place to put the Marking field.
   Why not just put the Marking field into the M-PDM Hop-by-Hop option, and
   use the existing PDM destination option for the rest of the M-PDM
   destination option functions? Note that Hop-by-Hop options certainly can be
   (and normally will be) processed by end nodes as well as intermediate
   systems; they are definitely always prepared by end nodes, since
   intermediate nodes are not allowed to insert extension headers or to modify
   their lengths.
   3. The M-PDM destination option type is specified as 0x0F, but that is
   already assigned to the PDM destination option. It does not appear to be
   backward compatible with the PDM option, so if it is defines, a new option
   type, to be assigned by the IANA, should be specified (e.g. TBD0).
   4. The document refers throughout to the M-PDM HBH Extension Header.
   Every instance should be changed to M-PDM HBH Option, since that's what it
   is. In fact this was what initially prompted me to look at the document; I
   thought a new HBH extension header was being defined, which RFC 8200 (and
   RFC 2460 before it) disallows. I know this is an editorial matter but it is
   important not to sow confusion.
   5. The M-PDM hop-by-hop option type is also specified as 0x0F, and
   again, a new option type, to be assigned by the IANA, should be specified
   (e.g. TBD1). Furthermore, since this option will change in flight, the
   value of the third high-order bit must be 1, not 0. Finally, since there is
   a single IANA IPv6 options registry that does not distinguish between
   destination options and hop-by-hop options (see
   https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2),
   it might be less confusing if this and the M-PDM destination option had
   different names, should both be defined.
   6. As the draft matures, you may want to solicit review from 6man.

Mike Heard

---

From: Nalini J Elkins <[email-masked]>
Date: Sun, 3 Jun 2018 12:40:14 +0000 (UTC)

Mike,

Thanks so much for your comments.

> I briefly perused https://tools.ietf.org/html/draft-fear-ippm-mpdm-00, and I have a few preliminary comments.

>    1. The M-PDM destination option layout and contents are very similar to those of the PDM option defined in RFC 8250, and initially I didn't grasp what additional purpose it > serves. The explanation does not come until Section 5 where the Marking field is finally discussed.. You would be doing your readers a huge favor to put the background
> discussion (and reference to RFC 8231) right up front. That is still recommended even if you accept the next comment.

Good suggestion.

>    2. As far as I was able to determine, the only real purpose of defining the M-PDM destination option is to have a place to put the Marking field. Why not just put the
> Marking field into the M-PDM Hop-by-Hop option, and use the existing PDM destination option for the rest of the M-PDM destination option functions? Note that Hop-by-Hop >options certainly can be (and normally will be) processed by end nodes as well as intermediate systems; they are definitely always prepared by end nodes, since intermediate >nodes are not allowed to insert extension headers or to modify their lengths.

The Marking field is already included in the M-PDM HBH Option.  The M-PDM destination option differs from the PDM destination option in that it is a fixed timebase and fixed scale.  But it is an interesting suggestion to use the M-PDM HBH by the end node as well.   Let me think about this a bit & talk over with co-authors.

>   3. The M-PDM destination option type is specified as 0x0F, but that is already assigned to the PDM destination option. It does not appear to be backward compatible with the >PDM option, so if it is defines, a new option type, to be assigned by the IANA, should be specified (e.g. TBD0).

Thanks.  

>    4. The document refers throughout to the M-PDM HBH Extension Header. Every instance should be changed to M-PDM HBH Option, since that's what it is. In fact this was what
> initially prompted me to look at the document; I thought a new HBH extension header was being defined, which RFC 8200 (and RFC 2460 before it) disallows. I know this is an
> editorial matter but it is important not to sow confusion.

Good point.  Thank you.

>    5. The M-PDM hop-by-hop option type is also specified as 0x0F, and again, a new option type, to be assigned by the IANA, should be specified (e.g. TBD1). Furthermore, since >this option will change in flight, the value of the third high-order bit must be 1, not 0. Finally, since there is a single IANA IPv6 options registry that does not distinguish >between destination options and hop-by-hop options (see https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2), it might be less confusing if >this and the M-PDM destination option had different names, should both be defined..

Thanks.

>  6. As the draft matures, you may want to solicit review from 6man. 

Yes, of course.  Our thinking was that we would get our thinking straight in IPPM and see what the group wanted to do and then maybe in Bangkok present at 6man.

We are, in particular, interested in people's thoughts on the Middlebox identifier field in the HBH option.   I think this will provide us with valuable measurements so it would be good to think carefully about what we might suggest as the identifier.

Thanks again for your thoughts.

Nalini