Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt

[[e-mail]]

Hi Greg,

Please see inline.

Cheers,
Med

De : sfc [mailto:[e-mail]] De la part de [e-mail]
Envoyé : vendredi 28 mai 2021 05:45
À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>
Cc : [e-mail]; [e-mail]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt


Hi Med,

many thanks for your help improving this document. I greatly appreciate your thoughtful and detailed comments. Please find my notes in-lined below under the GIM>> tag. I've atteched the working version and diff to highlight the proposed updates.

Regards,

Greg Mirsky

Sr. Standardization Expert
Original Mail
Sender: [e-mail]<mailto:[e-mail]>
To: Greg Mirsky;
CC: [e-mail]<mailto:[e-mail]>;
Date: 2021/05/26 00:09
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-multi-layer-oam-11.txt
Hi Greg,

Thank you for taking care of most of the comments. This version is much better.

I see that no changes were made to show how the requirements in Section 3 are met with the proposed solution. I'm sure you have good reasons for that.

GIM>> I just missed it. Would adding the new text below to the first paragraph of Section 5 be acceptable:

NEW TEXT:

  The SFC NSH Echo Request/Reply defined in this document

   addresses several requirements listed in Section 3.  Specifically, as

   defined in this specification, it can be used to check the continuity

   of an SFP, trace an SFP, localize the failure of the SFP.

[Med] Works for me. Thanks.

Also, I have one clarification question about the following:

(1)
   The sender of the Echo Request MAY use TLVs to
   request that the corresponding Echo Reply is transmitted over the

   specified path.

GIM>> I propose adding informational reference to draft-ao-sfc-oam-return-path-specified as follows:

[Med] I would prefer to have the content of ao-sfc-oam-return-path-specified included in draft-ietf-sfc-multi-layer-oam unless you are confident to progress that I-D separately. It is up to you.

NEW TEXT:

   [I-D.ao-sfc-oam-return-path-specified] provides an

   example of a TLV that can be used to specify the path of the Echo

   Reply.

(2)

   *  Reply via Specified Path (TBA8) value to enforce the use of the
      particular return path specified in the included TLV to verify bi-
      directional continuity and also increase the robustness of the
      monitoring by selecting a more stable path.

I fail to see which TLVs will be used to specify the "return path". Did I missed something?


GIM>> And here also can refer to draft-ao-sfc-oam-return-path-specified as follows:

NEW TEXT:

      [I-D.ao-sfc-oam-return-path-specified] provides an example of

      defining a specific path for the Echo Reply.

[Med]  Apologies for the late comment but when thinking about this part:
   To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID
   TLV [I-D.ietf-sfc-nsh-tlv<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-multi-layer-oam-11#ref-I-D.ietf-sfc-nsh-tlv>]v>].  The value of the Flow ID field of the
   SFP Echo Request packet MUST be set to the same value as of the
   monitored flow.

I failed to see how flow-id can be help for tracing (list if SFs that were involve in an SFP). Having a list of IP addresses is not sufficient as we need the identity of the SFs that were involved. The registry in draft-ietf-bess-nsh-bgp-control-plane-18#section-10.5 would be useful for this. If you can clarify that part in the text, that would be great. Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.