[ippm] Re: draft-mirsky-ippm-stamp-cos-ext

[[e-mail]]

Hi Greg,

Thank you for the thoughtful reply.
Please see inline.


Original


From: GregMirsky <[e-mail]>
To: 肖敏10093570;
Cc: [e-mail] <[e-mail]>;
Date: 2025年05月24日 07:06
Subject: Re: draft-mirsky-ippm-stamp-cos-ext




Hi Xiao Min,apologies for the delay to respond and thank you for your comments. I agree that explanation of interworking between CoS TLV as defined in Section 4.4 of RFC 8792 and the extended CoS is helpful. I propose adding a new section:
NEW TEXT:
3.1.  Interoperability with RFC 8972

   Consider two scenarios of interoperability between an implementation
   that supports the CoS TLV as defined in Section 4.4 of [RFC8972]
   (referred to as A) and the implementation that supports it as defined
   in this specification (referred to as B):

   *  A Session-Sender uses A and Session-Reflector - B.

   *  A Session-Sender uses B and Session-Reflector - A.

   In the former case, if A includes CoS TLV in the STAMP test packet,
   it zeroes the Reserved field.  When B receives the packet with CoS
   TLV, it uses the value of the REC field, which is 0b00, to set the
   ECN value in the IP header of the reflected STAMP test packet.

   In the latter case, regardless of the value set by B in the STAMP
   test packet, A, acting as Session-Reflector, will interpret it as
   part of the Reserved field and ignore the value according to
   Section 4.4 of [RFC8972].  Thus, A will set ECN in the IP header of
   the reflected STAMP test packet to 0b00.


What are your thoughts about the new section?
[XM]>>> Thanks for proposing the new section. To the processing of new added REC field, I think it's clear, just wonder why "Thus, A will set ECN in the IP header of the reflected STAMP test packet to 0b00", would not A set ECN at its own option? And I noticed that this specification updates the definition of RP field, would you like to mention the processing of RP field too in the new section?

Cheers,
Xiao Min

Regards,
Greg





On Tue, Apr 8, 2025 at 7:45 PM <[e-mail]> wrote:

Hi Greg,

Thank you for the concise and well-written draft.
I like the idea of making the new CoS TLV backward compatible with the existing CoS TLV defined in Section 4.4 of RFC 8972.
While reading the substantial part on the new definition of existing RP field and the new added REC field, I believe it's helpful to explain the existing definition of RP field here, in addition to the new definition. Furthermore, a new section explaining the backward compatibility, like Section 4.6 of RFC 8762, may make the advantages of this kind design more clear.

Best Regards,
Xiao Min