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

[[e-mail]]

Hi Greg,

Citing ao-sfc-oam-path-consistency is OK for the missing part about recording crossed SFs. However, I don’t see why flow-id is needed as the marking is done at the NSH level.

Thank you.

Cheers,
Med

De : [e-mail] [mailto:[e-mail]]
Envoyé : samedi 29 mai 2021 01:39
À : 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,

thank you the expedient response, Please find my follow-up notes in-lined below tagged GIM2>>.



Regards,

Greg Mirsky

[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>].  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.
 GIM2>> I much appreciate your comments and questions. I agree with you, Flow-id alone would not reflect SFs. I've updated the text adding the reference to draft-ao-sfc-oam-path-consistency. Mechanism described in that draft allows the collection of the SF Type information as specified
in the Service Function Type registry defined in draft-ietf-bess-nsh-bgp-control-plane.
NEW TEXT:

  To trace a particular RSP, the sender may use NSH MD Type 2 Flow ID

   TLV [I-D.ietf-sfc-nsh-tlv] in combination with the method described

   in [I-D.ao-sfc-oam-path-consistency].  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.
In Section 3.3 draft-ao-sfc-oam-path-consistency:

  SF Type: Two octets long field.  It is defined in

   [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF,

   e.g., Firewall, Deep Packet Inspection, WAN optimization controller,

   etc.

_________________________________________________________________________________________________________________________

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.