Re: Comments on draft-bocci-mpls-miad-adi-requirements

Hi Greg

Thank you for your comments. Please see below.

Matthew

From: Greg Mirsky <[email protected]>
Date: Friday, 4 March 2022 at 00:15
To: Bocci, Matthew (Nokia - GB) <[email protected]>
Cc: [email protected] <[email protected]>, mpls <[email protected]>, spring <[email protected]>, DetNet WG <[email protected]>
Subject: Re: Comments on draft-bocci-mpls-miad-adi-requirements
Hi Matthew and Stewart,
thank you for your work addressing my comments; much appreciated. I have several follow-up questions and comments to the new version of the draft, mostly to the new Section 3.1.2<https://datatracker.ietf.org/doc/html/draft-bocci-mpls-miad-adi-requirements#section-3.1.2>:

  *   I may suggest an editorial update to bullet 2
OLD TEXT:
   2.   A common mechanism for ancillary data MUST be defined so that a
        node receiving the ancillary data can determine whether to
        process, ignore or discard it.
NEW TEXT:
   2.   A common mechanism for ancillary data MUST be defined so that a
        node receiving the ancillary data can act according to the local policies.

MB> OK

  *   bullet 4 receives two notes:

     *   I think it should be a requirement, not a recommendation
     *   I think that an LSR must not be able to insert any ancillary data. Only ingress LER inserts data.

MB> OK


  *   it would be good if bullet 6 can be split into two
MB> The second part is a consequence of the first part, so they should probably stay together but we will rephrase to make this clearer.

  *   RE: bullet 7, I don't think that MPLS is the appropriate layer to guarantee in-order delivery. Should that be left to an application?
MB> This is not intended to be about MPLS guaranteeing in-order delivery, but rather whether the application can withstand out of order or “off line” or “slow path” processing or whether it requires in-line or fast path processing of ancillary data.

  *   it appears that bullet 8 is specific to the PSD case. If that is the case, should it refer to the BoS instead of "as close to the label stack as possible"?
MB> OK

  *   I think that having a requirement for the use of a common ancillary data header will help the discussion.
MB> We have modified the second requirement in “Ancillary Data Requirements” to reflect this.

Couple nits:

  *   "an/or" -> "and/or"
  *   s/lath/path/
Regards,
Greg

On Thu, Mar 3, 2022 at 3:58 AM Bocci, Matthew (Nokia - GB) <[email protected]<mailto:[email protected]>> wrote:
Hi Greg

Thank you for your detailed review and comments. We have tried to address these in the updated draft that we just posted.

In answer to your question below about whether the ancillary data needs a common format, I agree that it at least needs a common header format.

Regards

Matthew


From: Greg Mirsky <[email protected]<mailto:[email protected]>>
Date: Tuesday, 15 February 2022 at 20:18
To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>
Cc: mpls <[email protected]<mailto:[email protected]>>, spring <[email protected]<mailto:[email protected]>>, DetNet WG <[email protected]<mailto:[email protected]>>
Subject: Comments on draft-bocci-mpls-miad-adi-requirements
Hi Stewart and Matthew,
thank you for organizing this document in a very clear and concise manner. I enjoyed reading it.
Attached, please find a copy of the draft with my notes, comments, and suggestions. The most important, in my view, the question I have Should we add the requirement to have a common format for ancillary data defined?

Looking forward to your feedback.

Regards,
Greg

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals