Subject: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE: PoT review/comments)

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Thu, 19 Mar 2020 13:45:26 +0000

Dear SFC WG,

It’s been a while since we posted draft-ietf-sfc-proof-of-transit-04 which addressed all known comments – see below.
I’ve not seen any more recent comments or questions come up – and we’ve been through quite a few discussions and reviews of this document already.

Thus the question: Are we ready for WG LC?

Thanks, Frank

From: Frank Brockners (fbrockne)
Sent: Donnerstag, 21. November 2019 08:21
To: Alejandro Aguado FI <[email-masked]>; Diego R. Lopez <[email-masked]>; Carlos Pignataro (cpignata) <[email-masked]>; ALEJANDRO AGUADO MARTIN <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>; Tal Mizrahi <[email-masked]>
Cc: [email-masked]
Subject: RE: PoT review/comments

We’ve just posted revision -04 of draft-ietf-sfc-proof-of-transit which now includes support for OPOT configuration in the yang model;
see section 5.2.3 in  https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt.
The main addition is a grouping opot-profile, which adds upstream and downstream masks that OPOT requires.
Thanks to Alejandro for suggesting these updates.

This fixes the last “known issue” in draft-ietf-sfc-proof-of-transit. It would be great if you could give the document another careful read through.
Are we ready for WGLC?

Thanks, Frank

From: Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>>
Sent: Donnerstag, 12. September 2019 15:40
To: Diego R. Lopez <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: PoT review/comments

Hi Shwetha,

Yes, I think it is a good idea. From your points, the second one is a bit confusing to me... But I do not fully remember how the model was structured, so I need to revise the document.

Give me a day or two to explore again the model, and either we exchange few emails with proposals for the extension, or we can organise a quick call during next week to close a final proposal to share with other contributors.

Thanks!

Best,
Alejandro

El 12 de septiembre de 2019 a las 8:52:44, Shwetha Bhandari (shwethab) ([email-masked]<mailto:[email-masked]>) escribió:
Hi Alejandro, Diego,

Since you added extension to do OPoT, should we extend the model in draft-ietf-sfc-proof-of-transit to enable OPoT and any parameters required for it  shared masks per link. If yes my proposal will be to:

  1.  Augment existing pot-profile with fields to Enable OPoT and a cipher scheme if needed.
  2.  Separate container in the model to define a map of (Node link/interface, mask) to distribute pair wise masks. For e.g. Node link/interface identifier can be UUID as defined in rfc8348 Or
  3.  Masks can be part of pot-profile.

What do you think about revising the model with this?

Thanks,
Shwetha

From: "Frank Brockners (fbrockne)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 11, 2019 at 2:34 PM
To: ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>>, "Diego R. Lopez" <[email-masked]<mailto:[email-masked]>>, Carlos Pignataro <[email-masked]<mailto:[email-masked]>>, Shwetha bhandari <[email-masked]<mailto:[email-masked]>>, Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: PoT review/comments

Hi Alejandro,

Thanks again for the review. Your comments have been integrated into draft-ietf-sfc-proof-of-transit-03 which just got posted.

Cheers, Frank

From: Frank Brockners (fbrockne)
Sent: Montag, 27. Mai 2019 18:18
To: ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>>; Diego R. Lopez <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: PoT review/comments

Hi Alejandro,

Many thanks for the comments – and sorry for the delay – unfortunately your email somehow got dropped from my todo list. Please see inline…

(cc’ing the list as well).

From: ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>>
Sent: Montag, 15. April 2019 17:27
To: Diego R. Lopez <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: PoT review/comments

Dear all,

I gave a quick review to the PoT document. Some comments:

- I read “The non-constant coefficients are used to generate the Lagrange Polynomial Constants (LPC).” As far as I understood, the points assigned to each node (Xi) are the ones used for generating the LPCi, aren’t they?
…FB: Good catch. The LPCs are of course computed using (x_i, y_i).
- If we go for including the YANG in the current document (which I agree), parameters should be described before the yang definition, and maybe it would be helpful to have the yang tree (see the current version attached).
…FB: Thanks. IMHO it makes sense to keep the YANG model in the current doc, given that the model and the description go hand in hand. We can of course also include the yang tree to make reading easier. This is consistent with other documents which specify YANG models.
- I include in the attached file few questions about naming of some parameters.

…FB:
- naming F_i(x_i, y_i) – I agree that a better name could be used. The only potential concern would be that the open source implementation in OpenDaylight uses this naming – changing it might lead to confusion. We can start with adding a comment to make things clearer.

- secret key – this is the constant part of the first polynomial which serves as the secret – and which is re-retrieved. Again, we can update the description to make things clearer.

- size of the random number: This is unrelated to OPOT. The random number is to uniquely identify a packet. There is a trade-off between the size of the random number and how often you need to re-key your system. At high speeds, the random number – which identifies a particular packet – is used up quite quickly if it is only 32-bit wide. See section 4  https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4

- number of profiles: For a deployment which is expected to renew keys every now and then (e.g. you run with 32-bit random numbers at reasonably high speeds), you need at least 2 profiles – an active one and one that you can activate once you run out of random numbers (which is what the encapsulating node would decide).
- I have checked some of the existing YANG files within the IETF to see in which it would be helpful to include. From the (not so) old OpenFlow, I assume that one match is necessary (for identify the iOAM/PoT header) whilst the source node can use any existing match field to identify packets where to apply the PoT scheme. In terms of actions, I would say that two may be required: for any node, an update-pot is necessary, while the verifier would need a verify-pot type of action, that would ideally either remove the header or drop the packet if fails (I do not know if you are thinking in more complex scenarios).

…FB: From an OF perspective, that sounds feasible. That said, we probably want to avoid making the spec specific to a technology like OF, hence would suggest that we don’t specify such a behavior as part of this document.

- For this last point, I have seen the definitions within draft-asechoud-rtgwg-qos-model-08, where matched could map (if I am not wrong) to classifiers/filters, and actions to actions. I send you the models in a zip file. In this sense the model to be defined in the PoT shall be an augment of the models defined in that document. I have not done a very deep revision on the model, but I think it could fit there. If you have check this or other models, let me know so I could also help.

…FB: Per my note above: In order to keep POT generic and not link it to a particular classification mechanism, I’d prefer to keep the classification question as out of scope for the current document. That way it can also apply to technologies which come with their own way to classify – and which might fully decouple the tunneling aspects from the classification aspects.

Thanks a lot and sorry for such long email.

..FB: Thanks again for all your comments. We’ll get them included in the next revision.

Cheers, Frank

Best,
Alejandro

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 19 Mar 2020 16:23:18 +0000

Frank,

To me, there are two documents in SFC which are ready for a WGLC:
* draft-ietf-sfc-ioam-nsh-03.txt
* draft-ietf-sfc-proof-of-transit-04.txt

But that’s simply my participant+contributor opinion only. They are technically and editorially stable and complete, in my humble opinion.

Jim, Joel,

As chains, what’s your view on readiness for these two stable documents for SFC WGLC? If ready, could you initiate a WGLC? What would otherwise be needed?

Thanks!

Carlos.

2020/03/19 午前9:45、Frank Brockners (fbrockne) <[email-masked]<mailto:[email-masked]>>のメール:

Dear SFC WG,

Thanks, Frank

To: Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>>; Diego R. Lopez <[email-masked]<mailto:[email-masked]>>; Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>>; ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>>; Shwetha Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>>

Thanks, Frank

Hi Shwetha,

Thanks!

Best,
Alejandro

Hi Alejandro, Diego,

Thanks,
Shwetha

Hi Alejandro,

Cheers, Frank

Hi Alejandro,

Dear all,

…FB:

Cheers, Frank

Best,
Alejandro

---

From: James Guichard <[email-masked]>
Date: Thu, 19 Mar 2020 17:43:29 +0000

Hi Carlos,

The chairs see no outstanding issues to prevent us from issuing WG LCs for these documents once the WG has had a few days to respond to Frank's previous email.

Thanks!

Jim & Joel

From: Carlos Pignataro (cpignata) <[email-masked]>
Sent: Thursday, March 19, 2020 12:23 PM
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: Alejandro Aguado FI <[email-masked]>; Diego R. Lopez <[email-masked]>; ALEJANDRO AGUADO MARTIN <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>; Tal Mizrahi <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE: PoT review/comments)

Frank,

Jim, Joel,

Thanks!

Carlos.

Dear SFC WG,

Thanks, Frank

We’ve just posted revision -04 of draft-ietf-sfc-proof-of-transit which now includes support for OPOT configuration in the yang model;
see section 5.2.3 in  https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-sfc-proof-of-transit-04.txt&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C358349d747604b63286f08d7cc21dcdb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637202318127887503&sdata=Cnwa9lJa91zxpWRq6Z7EISmeDk03rvXNCjpnpzFpF0I%3D&reserved=0>.
The main addition is a grouping opot-profile, which adds upstream and downstream masks that OPOT requires.
Thanks to Alejandro for suggesting these updates.

Thanks, Frank

Hi Shwetha,

Thanks!

Best,
Alejandro

Thanks,
Shwetha

Hi Alejandro,

Cheers, Frank

Hi Alejandro,

Dear all,

…FB:

- size of the random number: This is unrelated to OPOT. The random number is to uniquely identify a packet. There is a trade-off between the size of the random number and how often you need to re-key your system. At high speeds, the random number – which identifies a particular packet – is used up quite quickly if it is only 32-bit wide. See section 4  https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-sfc-proof-of-transit-02%23section-4&data=02%7C01%7Cjames.n.guichard%40futurewei.com%7C358349d747604b63286f08d7cc21dcdb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637202318127897458&sdata=UaIF2KBiqXjVw0Nag3HUTBhMp7KVchdvhLPyMpCbgL0%3D&reserved=0>

Cheers, Frank

Best,
Alejandro

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Mar 2020 13:26:44 -0700

Hi Frank,
thank you for reminding us about this important work, indeed we should
complete it. I've reviewed the draft and have several questions. Please
kindly consider:

   - I couldn't find information where, relative to NSH, RND and CML are
   transported
   - for YANG data models using "reference" is strongly encouraged as it
   provides a pointer to the specification. Since the POT data model is in the
   same document as the POT specification, listing the appropriate section
   should suffice

Regards,
Greg

On Thu, Mar 19, 2020 at 6:45 AM Frank Brockners (fbrockne) <fbrockne=
[email-masked]> wrote:

> Dear SFC WG,
>
>
>
> It’s been a while since we posted draft-ietf-sfc-proof-of-transit-04 which
> addressed all known comments – see below.
> I’ve not seen any more recent comments or questions come up – and we’ve
> been through quite a few discussions and reviews of this document already.
>
>
>
> *From:* Frank Brockners (fbrockne)
> *Sent:* Donnerstag, 21. November 2019 08:21
> *To:* Alejandro Aguado FI <[email-masked]>; Diego R. Lopez <
> [email-masked]>; Carlos Pignataro (cpignata) <
> [email-masked]>; ALEJANDRO AGUADO MARTIN <
> [email-masked]>; Shwetha Bhandari (shwethab) <
> [email-masked]>; Tal Mizrahi <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: PoT review/comments
>
>
>
> We’ve just posted revision -04 of draft-ietf-sfc-proof-of-transit which
> now includes support for OPOT configuration in the yang model;
>
> see section 5.2.3 in
> https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt.
>
> This fixes the last “known issue” in draft-ietf-sfc-proof-of-transit. It
> would be great if you could give the document another careful read through.
> Are we ready for WGLC?
>
>
>
> Thanks, Frank
>
>
>
>
>
> *From:* Alejandro Aguado FI <[email-masked]>
> *Sent:* Donnerstag, 12. September 2019 15:40
> *To:* Diego R. Lopez <[email-masked]>; Carlos Pignataro
> (cpignata) <[email-masked]>; Frank Brockners (fbrockne) <
> [email-masked]>; ALEJANDRO AGUADO MARTIN <
> [email-masked]>; Shwetha Bhandari (shwethab) <
> [email-masked]>; Tal Mizrahi <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: PoT review/comments
>
>
>
> Hi Shwetha,
>
>
>
> Yes, I think it is a good idea. From your points, the second one is a bit
> confusing to me... But I do not fully remember how the model was
> structured, so I need to revise the document.
>
>
>
> Give me a day or two to explore again the model, and either we exchange
> few emails with proposals for the extension, or we can organise a quick
> call during next week to close a final proposal to share with other
> contributors.
>
>
>
> Thanks!
>
>
>
> Best,
>
> Alejandro
>
>
>
>
>
> El 12 de septiembre de 2019 a las 8:52:44, Shwetha Bhandari (shwethab) (
> [email-masked]) escribió:
>
> Hi Alejandro, Diego,
>
>
>
> Since you added extension to do OPoT, should we extend the model in
> draft-ietf-sfc-proof-of-transit to enable OPoT and any parameters required
> for it  shared masks per link. If yes my proposal will be to:
>
>    2. Separate container in the model to define a map of (Node
>    link/interface, mask) to distribute pair wise masks. For e.g. Node
>    link/interface identifier can be UUID as defined in rfc8348 Or
> *From: *"Frank Brockners (fbrockne)" <[email-masked]>
> *Date: *Wednesday, September 11, 2019 at 2:34 PM
> *To: *ALEJANDRO AGUADO MARTIN <[email-masked]>,
> "Diego R. Lopez" <[email-masked]>, Carlos Pignataro <
> [email-masked]>, Shwetha bhandari <[email-masked]>, Tal Mizrahi <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *RE: PoT review/comments
>
>
>
> Hi Alejandro,
>
>
>
> Thanks again for the review. Your comments have been integrated into
> draft-ietf-sfc-proof-of-transit-03 which just got posted.
>
>
>
> Cheers, Frank
>
>
>
> *From:* Frank Brockners (fbrockne)
> *Sent:* Montag, 27. Mai 2019 18:18
> *To:* ALEJANDRO AGUADO MARTIN <[email-masked]>;
> Diego R. Lopez <[email-masked]>; Carlos Pignataro
> (cpignata) <[email-masked]>; Shwetha Bhandari (shwethab) <
> [email-masked]>; Tal Mizrahi <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* RE: PoT review/comments
>
>
>
> Hi Alejandro,
>
>
>
> Many thanks for the comments – and sorry for the delay – unfortunately
> your email somehow got dropped from my todo list. Please see inline…
>
>
>
> *From:* ALEJANDRO AGUADO MARTIN <[email-masked]>
>
> *Sent:* Montag, 15. April 2019 17:27
> *To:* Diego R. Lopez <[email-masked]>; Carlos Pignataro
> (cpignata) <[email-masked]>; Frank Brockners (fbrockne) <
> [email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>;
> Tal Mizrahi <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* PoT review/comments
>
>
>
> Dear all,
>
>
>
> - I read “The non-constant coefficients are used to generate the Lagrange
> Polynomial Constants (LPC).” As far as I understood, the points assigned to
> each node (Xi) are the ones used for generating the LPCi, aren’t they?
>
> *…FB: Good catch. The LPCs are of course computed using (x_i, y_i).*
>
> - If we go for including the YANG in the current document (which I agree),
> parameters should be described before the yang definition, and maybe it
> would be helpful to have the yang tree (see the current version attached).
>
> *…FB: Thanks. IMHO it makes sense to keep the YANG model in the current
> doc, given that the model and the description go hand in hand. We can of
> course also include the yang tree to make reading easier. This is
> consistent with other documents which specify YANG models.*
>
> *…FB: - naming F_i(x_i, y_i) – I agree that a better name could be used.
> The only potential concern would be that the open source implementation in
> OpenDaylight uses this naming – changing it might lead to confusion. We can
> start with adding a comment to make things clearer.*
>
>
>
> *- secret key – this is the constant part of the first polynomial which
> serves as the secret – and which is re-retrieved. Again, we can update the
> description to make things clearer.*
>
>
>
> *- size of the random number: This is unrelated to OPOT. The random number
> is to uniquely identify a packet. There is a trade-off between the size of
> the random number and how often you need to re-key your system. At high
> speeds, the random number – which identifies a particular packet – is used
> up quite quickly if it is only 32-bit wide. See section 4  *
> https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4
>
>
>
> *- number of profiles: For a deployment which is expected to renew keys
> every now and then (e.g. you run with 32-bit random numbers at reasonably
> high speeds), you need at least 2 profiles – an active one and one that you
> can activate once you run out of random numbers (which is what the
> encapsulating node would decide). *
>
> - I have checked some of the existing YANG files within the IETF to see in
> which it would be helpful to include. From the (not so) old OpenFlow, I
> assume that one match is necessary (for identify the iOAM/PoT header)
> whilst the source node can use any existing match field to identify packets
> where to apply the PoT scheme. In terms of actions, I would say that two
> may be required: for any node, an update-pot is necessary, while the
> verifier would need a verify-pot type of action, that would ideally either
> remove the header or drop the packet if fails (I do not know if you are
> thinking in more complex scenarios).
>
>
>
> *…FB: From an OF perspective, that sounds feasible. That said, we probably
> want to avoid making the spec specific to a technology like OF, hence would
> suggest that we don’t specify such a behavior as part of this document.*
>
>
>
> - For this last point, I have seen the definitions within
> draft-asechoud-rtgwg-qos-model-08, where matched could map (if I am not
> wrong) to classifiers/filters, and actions to actions. I send you the
> models in a zip file. In this sense the model to be defined in the PoT
> shall be an augment of the models defined in that document. I have not done
> a very deep revision on the model, but I think it could fit there. If you
> have check this or other models, let me know so I could also help.
>
>
>
> *…FB: Per my note above: In order to keep POT generic and not link it to a
> particular classification mechanism, I’d prefer to keep the classification
> question as out of scope for the current document. That way it can also
> apply to technologies which come with their own way to classify – and which
> might fully decouple the tunneling aspects from the classification aspects.
> *
>
>
>
> *..FB: Thanks again for all your comments. We’ll get them included in the
> next revision. *
>
>
>
> *Cheers, Frank*
>
>
>
>
>
>
>
> Best,
>
> Alejandro
>
>
>
>
>
>
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Mar 2020 16:42:32 -0400

Regarding the information carriage, the PoT document points to the IOAM 
document.
https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08#section-4.5 
gives the format (and ways to have other formats if needed.)

Yours,
Joel

On 3/24/2020 4:26 PM, Greg Mirsky wrote:
>   * I couldn't find information where, relative to NSH, RND and CML are
>     transported
>   * for YANG data models using "reference" is strongly encouraged as it
>     provides a pointer to the specification. Since the POT data model is
>     in the same document as the POT specification, listing the
>     appropriate section should suffice
> 
> Regards,
> Greg
> 
> On Thu, Mar 19, 2020 at 6:45 AM Frank Brockners (fbrockne) 
> <fbrockne=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Dear SFC WG,____
> 
>     __ __
> 
>     It’s been a while since we posted draft-ietf-sfc-proof-of-transit-04
>     which addressed all known comments – see below.
>     I’ve not seen any more recent comments or questions come up – and
>     we’ve been through quite a few discussions and reviews of this
>     document already.____
> 
>     __ __
> 
>     Thus the question: Are we ready for WG LC?____
> 
>     __ __
> 
>     Thanks, Frank____
> 
>     __ __
> 
>     *To:* Alejandro Aguado FI <[email-masked]
>     <mailto:[email-masked]>>; Diego R. Lopez
>     <[email-masked]
>     <mailto:[email-masked]>>; Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>; ALEJANDRO AGUADO
>     MARTIN <[email-masked]
>     <mailto:[email-masked]>>; Shwetha
>     Bhandari (shwethab) <[email-masked]
>     <mailto:[email-masked]>>; Tal Mizrahi <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* RE: PoT review/comments____
> 
>     __ __
> 
>     We’ve just posted revision -04 of draft-ietf-sfc-proof-of-transit
>     which now includes support for OPOT configuration in the yang model;____
> 
>     see section 5.2.3 in
>     https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt. ____
> 
>     The main addition is a grouping opot-profile, which adds upstream
>     and downstream masks that OPOT requires.____
> 
>     Thanks to Alejandro for suggesting these updates.____
> 
>     __ __
> 
>     This fixes the last “known issue” in
>     draft-ietf-sfc-proof-of-transit. It would be great if you could give
>     the document another careful read through.
>     Are we ready for WGLC?____
> 
>     __ __
> 
>     Thanks, Frank____
> 
>     __ __
> 
>     __ __
> 
>     *From:* Alejandro Aguado FI <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Diego R. Lopez <[email-masked]
>     <mailto:[email-masked]>>; Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>; Frank Brockners
>     (fbrockne) <[email-masked] <mailto:[email-masked]>>;
>     ALEJANDRO AGUADO MARTIN <[email-masked]
>     <mailto:[email-masked]>>; Shwetha
>     Bhandari (shwethab) <[email-masked]
>     <mailto:[email-masked]>>; Tal Mizrahi <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: PoT review/comments____
> 
>     __ __
> 
>     Hi Shwetha,____
> 
>     __ __
> 
>     Yes, I think it is a good idea. From your points, the second one is
>     a bit confusing to me... But I do not fully remember how the model
>     was structured, so I need to revise the document.____
> 
>     __ __
> 
>     Give me a day or two to explore again the model, and either we
>     exchange few emails with proposals for the extension, or we can
>     organise a quick call during next week to close a final proposal to
>     share with other contributors.____
> 
>     __ __
> 
>     Thanks!____
> 
>     __ __
> 
>     Best,____
> 
>     Alejandro____
> 
>     __ __
> 
>     __ __
> 
>     El 12 de septiembre de 2019 a las 8:52:44, Shwetha Bhandari
>     (shwethab) ([email-masked] <mailto:[email-masked]>)
>     escribió:____
> 
>     Hi Alejandro, Diego,____
> 
>     ____
> 
>     draft-ietf-sfc-proof-of-transit to enable OPoT and any parameters
>     required for it  shared masks per link. If yes my proposal will be
>     to:____
> 
>      1. Augment existing pot-profile with fields to Enable OPoT and a
>         cipher scheme if needed.____
>         link/interface, mask) to distribute pair wise masks. For e.g.
>         Node link/interface identifier can be UUID as defined in rfc8348
>         Or____
>      3. Masks can be part of pot-profile.____
> 
>     ____
> 
>     What do you think about revising the model with this?____
> 
>     ____
> 
>     Thanks,____
> 
>     Shwetha____
> 
>     ____
> 
>     *From: *"Frank Brockners (fbrockne)" <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *ALEJANDRO AGUADO MARTIN
>     <[email-masked]
>     <mailto:[email-masked]>>, "Diego R.
>     Lopez" <[email-masked]
>     <mailto:[email-masked]>>, Carlos Pignataro
>     <cpignata@cisco..com <mailto:[email-masked]>>, Shwetha bhandari
>     <[email-masked] <mailto:[email-masked]>>, Tal Mizrahi
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Subject: *RE: PoT review/comments____
> 
>     ____
> 
>     Hi Alejandro,____
> 
>     ____
> 
>     draft-ietf-sfc-proof-of-transit-03 which just got posted.____
> 
>     ____
> 
>     Cheers, Frank____
> 
>     ____
> 
>     *From:*Frank Brockners (fbrockne)
>     *To:* ALEJANDRO AGUADO MARTIN
>     <[email-masked]
>     <mailto:[email-masked]>>; Diego R. Lopez
>     <[email-masked]
>     <mailto:[email-masked]>>; Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>; Shwetha Bhandari
>     (shwethab) <[email-masked] <mailto:[email-masked]>>; Tal
>     Mizrahi <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* RE: PoT review/comments____
> 
>     ____
> 
>     Hi Alejandro,____
> 
>     ____
> 
>     Many thanks for the comments – and sorry for the delay –
>     unfortunately your email somehow got dropped from my todo list.
>     Please see inline…____
> 
>     ____
> 
>     (cc’ing the list as well).____
> 
>     ____
> 
>     *From:*ALEJANDRO AGUADO MARTIN
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Diego R. Lopez <[email-masked]
>     <mailto:[email-masked]>>; Carlos Pignataro (cpignata)
>     <[email-masked] <mailto:[email-masked]>>; Frank Brockners
>     (fbrockne) <[email-masked] <mailto:[email-masked]>>; Shwetha
>     Bhandari (shwethab) <[email-masked]
>     <mailto:[email-masked]>>; Tal Mizrahi <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     *Subject:* PoT review/comments____
> 
>     ____
> 
>     Dear all,____
> 
>     ____
> 
>     I gave a quick review to the PoT document. Some comments:____
> 
>     ____
> 
>     - I read “The non-constant coefficients are used to generate the
>     Lagrange Polynomial Constants (LPC).” As far as I understood, the
>     points assigned to each node (Xi) are the ones used for generating
>     the LPCi, aren’t they?____
> 
>     */…FB: Good catch. The LPCs are of course computed using (x_i,
>     y_i)./*____
> 
>     - If we go for including the YANG in the current document (which I
>     agree), parameters should be described before the yang definition,
>     and maybe it would be helpful to have the yang tree (see the current
>     version attached).____
> 
>     */…FB: Thanks. IMHO it makes sense to keep the YANG model in the
>     current doc, given that the model and the description go hand in
>     hand. We can of course also include the yang tree to make reading
>     easier. This is consistent with other documents which specify YANG
>     models./*____
> 
>     - I include in the attached file few questions about naming of some
>     parameters.____
> 
>     *//*____
> 
>     */…FB:
>     - naming F_i(x_i, y_i) – I agree that a better name could be used.
>     The only potential concern would be that the open source
>     implementation in OpenDaylight uses this naming – changing it might
>     lead to confusion.. We can start with adding a comment to make
>     things clearer./*____
> 
>     *//*____
> 
>     */- secret key – this is the constant part of the first polynomial
>     which serves as the secret – and which is re-retrieved. Again, we
>     can update the description to make things clearer./*____
> 
>     *//*____
> 
>     */- size of the random number: This is unrelated to OPOT. The random
>     number is to uniquely identify a packet. There is a trade-off
>     between the size of the random number and how often you need to
>     re-key your system. At high speeds, the random number – which
>     identifies a particular packet – is used up quite quickly if it is
>     only 32-bit wide. See section 4
>     /*https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4____
> 
>     *//*____
> 
>     */- number of profiles: For a deployment which is expected to renew
>     keys every now and then (e.g. you run with 32-bit random numbers at
>     reasonably high speeds), you need at least 2 profiles – an active
>     one and one that you can activate once you run out of random numbers
>     (which is what the encapsulating node would decide). /*____
> 
>     - I have checked some of the existing YANG files within the IETF to
>     see in which it would be helpful to include. From the (not so) old
>     OpenFlow, I assume that one match is necessary (for identify the
>     iOAM/PoT header) whilst the source node can use any existing match
>     field to identify packets where to apply the PoT scheme. In terms of
>     actions, I would say that two may be required: for any node, an
>     update-pot is necessary, while the verifier would need a verify-pot
>     type of action, that would ideally either remove the header or drop
>     the packet if fails (I do not know if you are thinking in more
>     complex scenarios).____
> 
>     *//*____
> 
>     */…FB: From an OF perspective, that sounds feasible.. That said, we
>     probably want to avoid making the spec specific to a technology like
>     OF, hence would suggest that we don’t specify such a behavior as
>     part of this document./*____
> 
>     *//*____
> 
>     draft-asechoud-rtgwg-qos-model-08, where matched could map (if I am
>     not wrong) to classifiers/filters, and actions to actions. I send
>     you the models in a zip file. In this sense the model to be defined
>     in the PoT shall be an augment of the models defined in that
>     document. I have not done a very deep revision on the model, but I
>     think it could fit there. If you have check this or other models,
>     let me know so I could also help.____
> 
>     *//*____
> 
>     */…FB: Per my note above: In order to keep POT generic and not link
>     it to a particular classification mechanism, I’d prefer to keep the
>     classification question as out of scope for the current document.
>     That way it can also apply to technologies which come with their own
>     way to classify – and which might fully decouple the tunneling
>     aspects from the classification aspects. /*____
> 
>     ____
> 
>     Thanks a lot and sorry for such long email.____
> 
>     ____
> 
>     */..FB: Thanks again for all your comments. We’ll get them included
>     in the next revision. /*____
> 
>     *//*____
> 
>     */Cheers, Frank/*____
> 
>     ____
> 
>     ____
> 
>     ____
> 
>     Best,____
> 
>     Alejandro____
> 
>     ____
> 
>     ____
> 
>     ____
> 
>     ____
> 
>     ------------------------------------------------------------------------
> 
> 
>     Este mensaje y sus adjuntos se dirigen exclusivamente a su
>     destinatario, puede contener información privilegiada o confidencial
>     y es para uso exclusivo de la persona o entidad de destino. Si no es
>     usted. el destinatario indicado, queda notificado de que la lectura,
>     utilización, divulgación y/o copia sin autorización puede estar
>     prohibida en virtud de la legislación vigente. Si ha recibido este
>     mensaje por error, le rogamos que nos lo comunique inmediatamente
>     por esta misma vía y proceda a su destrucción.
> 
>     confidential information intended only for the use of the individual
>     or entity named above. If the reader of this message is not the
>     intended recipient, you are hereby notified that any dissemination,
>     distribution or copying of this communication is strictly
>     prohibited. If you have received this transmission in error, do not
>     read it. Please immediately reply to the sender that you have
>     received this communication in error and then delete it.
> 
>     Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>     destinatário, pode conter informação privilegiada ou confidencial e
>     é para uso exclusivo da pessoa ou entidade de destino. Se não é
>     vossa senhoria o destinatário indicado, fica notificado de que a
>     leitura, utilização, divulgação e/ou cópia sem autorização pode
>     estar proibida em virtude da legislação vigente. Se recebeu esta
>     mensagem por erro, rogamos-lhe que nos o comunique imediatamente por
>     esta mesma via e proceda a sua destruição____
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Mar 2020 13:48:43 -0700

Hi Joel,
thank you for the most expedient response. As I understand it, iOAM Data
draft describes the format of the informational element that carries
POT-related information but it does not define how the element to be
carried in case of NSH encapsulation. And that is what I was asking,
apologies for not being clear in my first note.

Regards,
Greg

On Tue, Mar 24, 2020 at 1:42 PM Joel M. Halpern <[email-masked]> wrote:

> >     Mizrahi <[email-masked] <mailto:[email-masked]
> >>
> >     /*
> https://tools.ietf.org/html/draft-ietf-sfc-proof-of-transit-02#section-4____
> >
> >     *//*____
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 24 Mar 2020 20:54:56 +0000

Greg,

The very first sentence of the PoT document reads:

   Several technologies such as Traffic Engineering (TE), Service
   Function Chaining (SFC), and policy based routing are used to steer
   traffic through a specific, user-defined path.  This document defines

Explaining how this document is applicable to various traffic-steering technologies.

Section 3 then explains:

   The POT information is encapsulated in packets as an IOAM Proof Of
   Transit Option.  The details and format of the encapsulation and the
   POT Option format are specified in [I-D.ietf-ippm-ioam-data].

Which shows how to carry PoT in IOAM, with an appropriate pointer.

Lastly, draft-ietf-sfc-ioam-nsh-03 defines IOAM over an NSH encapsulation.

This arrangements maximizes specification modularity and portability/reusability.

Best,

Carlos.

2020/03/24 午後4:48、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Hi Joel,
thank you for the most expedient response. As I understand it, iOAM Data draft describes the format of the informational element that carries POT-related information but it does not define how the element to be carried in case of NSH encapsulation. And that is what I was asking, apologies for not being clear in my first note.

Regards,
Greg

On Tue, Mar 24, 2020 at 1:42 PM Joel M.. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
Regarding the information carriage, the PoT document points to the IOAM
document.
https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08#section-4.5
gives the format (and ways to have other formats if needed.)

Yours,
Joel

On 3/24/2020 4:26 PM, Greg Mirsky wrote:
> <fbrockne=[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     Dear SFC WG,____
>
>     __ __
>
>     *To:* Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Diego R. Lopez
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:cpignata@cisco..com>>>; ALEJANDRO AGUADO
>     MARTIN <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Shwetha
>     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     *From:* Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *To:* Diego R. Lopez <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:cpignata@cisco..com>>>; Frank Brockners
>     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>;
>     ALEJANDRO AGUADO MARTIN <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Shwetha
>     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     (shwethab) ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>)
>     escribió:____
>
>     Hi Alejandro, Diego,____
>
>     ____
>
>     *From: *"Frank Brockners (fbrockne)" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>, "Diego R.
>     Lopez" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>, Carlos Pignataro
>     <cpignata@cisco..com <mailto:[email-masked]<mailto:[email-masked]>>>, Shwetha bhandari
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:shwethab@cisco..com>>>, Tal Mizrahi
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>"
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Diego R. Lopez
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:cpignata@cisco..com>>>; Shwetha Bhandari
>     (shwethab) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Tal
>     Mizrahi <[email-masked]<mailto:tal.mizrahi.phd@gmail..com> <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *To:* Diego R. Lopez <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:cpignata@cisco..com>>>; Frank Brockners
>     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>; Shwetha
>     Bhandari (shwethab) <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>; Tal Mizrahi <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>>
>     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     (which is what the encapsulating node would decide).. /*____
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Mar 2020 14:00:14 -0700

Hi Carlos,
thank you for the clarification. My understanding, that the reason the POT
document being worked by the SFC WG is that it defines it for the
NSH encapsulation. Or is the applicability of
the draft-ietf-sfc-proof-of-transit border than SFC using NSH?

Regards,
Greg

On Tue, Mar 24, 2020 at 1:55 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 2020/03/24 午後4:48、Greg Mirsky <[email-masked]>のメール:
>
> Hi Joel,
> On Tue, Mar 24, 2020 at 1:42 PM Joel M.. Halpern <[email-masked]>
> wrote:
>
>> >     <[email-masked] <mailto:[email-masked]
>> <cpignata@cisco..com>>>; ALEJANDRO AGUADO
>> <[email-masked]>
>> >     <mailto:[email-masked]
>> <[email-masked]>>>; Shwetha
>> <[email-masked]>
>> >     <[email-masked] <mailto:[email-masked]
>> <cpignata@cisco..com>>>; Frank Brockners
>> >     <mailto:[email-masked]
>> <[email-masked]>>>; Shwetha
>> >     <mailto:[email-masked]
>> <[email-masked]>>>, "Diego R.
>> >     <[email-masked] <mailto:[email-masked]
>> <shwethab@cisco..com>>>, Tal Mizrahi
>> >     <mailto:[email-masked]
>> <[email-masked]>>>; Diego R. Lopez
>> >     <[email-masked] <mailto:[email-masked]
>> <cpignata@cisco..com>>>; Shwetha Bhandari
>> >     Mizrahi <[email-masked] <tal.mizrahi.phd@gmail..com>
>> >     <mailto:[email-masked]
>> <[email-masked]>>>
>> >     <[email-masked] <mailto:[email-masked]
>> <cpignata@cisco..com>>>; Frank Brockners

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Mar 2020 17:10:37 -0400

Carlos, it sounds like there should probably be a normative reference 
from draft-ietf-sfc-proof of transit to draft-ietf-sfc-ioam-nsh? 
Possibly in the same sentence that refers to draft-ietf-ippm-ioam-data?

Yours,
Joel

On 3/24/2020 4:54 PM, Carlos Pignataro (cpignata) wrote:
>> thank you for the most expedient response. As I understand it, iOAM 
>> Data draft describes the format of the informational element that 
>> carries POT-related information but it does not define how the element 
>> to be carried in case of NSH encapsulation. And that is what I was 
>> asking, apologies for not being clear in my first note.
>>
>> Regards,
>> Greg
>>
>>     <mailto:[email-masked]>
>>     > <mailto:[email-masked]
>>     <mailto:[email-masked]>>> wrote:
>>     >
>>     >     Dear SFC WG,____
>>     >
>>     >     __ __
>>     >
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     Diego R. Lopez
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:cpignata@cisco..com>>>;
>>     ALEJANDRO AGUADO
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>>>; Shwetha
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     Tal Mizrahi <[email-masked]
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Frank
>>     Brockners
>>     >     (fbrockne) <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     >     ALEJANDRO AGUADO MARTIN
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>>>; Shwetha
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     Tal Mizrahi <[email-masked]
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>
>>     >     (shwethab) ([email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>)
>>     >     escribió:____
>>     >
>>     >     Hi Alejandro, Diego,____
>>     >
>>     >     ____
>>     >
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>>>, "Diego R.
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>, Carlos Pignataro
>>     >     <cpignata@cisco..com <mailto:[email-masked]
>>     <mailto:[email-masked]>>>, Shwetha bhandari
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:shwethab@cisco..com>>>, Tal Mizrahi
>>     >     <[email-masked]
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>
>>     >     *Cc: *"[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>"
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>,
>>     "[email-masked] <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]
>>     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>>>; Diego R. Lopez
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Shwetha
>>     Bhandari
>>     >     (shwethab) <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>; Tal
>>     >     Mizrahi <[email-masked]
>>     <mailto:tal.mizrahi.phd@gmail..com>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>
>>     <mailto:[email-masked] <mailto:[email-masked]>>;
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>>>
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked]
>>     <mailto:[email-masked]>>>; Carlos Pignataro (cpignata)
>>     >     <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:cpignata@cisco..com>>>; Frank
>>     Brockners
>>     >     (fbrockne) <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>>; Shwetha
>>     <mailto:[email-masked]>
>>     >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>     Tal Mizrahi <[email-masked]
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>
>>     > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>     <mailto:[email-masked]>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 24 Mar 2020 21:15:00 +0000

Hi, Greg,

I cannot speak to your understanding, or where it is rooted on.

And I believe you meant “broader” instead of “border”.

Reading the very first sentence of the document (and the full Abstract) explains what you are asking below, in better words than what I can answer here.

And those are, however, questions about WG adoption, which happened about two years ago.

That said, PoT over NSH is a cardinal application and early use case, and as such, was adopted by the SFC WG (for generic PoT and IOAM over NSH).

Best,

Carlos.

2020/03/24 午後5:00、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Hi Carlos,
thank you for the clarification. My understanding, that the reason the POT document being worked by the SFC WG is that it defines it for the NSH encapsulation. Or is the applicability of the draft-ietf-sfc-proof-of-transit border than SFC using NSH?

Regards,
Greg

On Tue, Mar 24, 2020 at 1:55 PM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Section 3 then explains:

Best,

Carlos.

Hi Joel,

Regards,
Greg

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 24 Mar 2020 21:20:47 +0000

Hi, Joel,

The way in which the doc hierarchy and relationship is structure seems to support and potentially even require:

From draft-ietf-sfc-proof-of-transit:
* A normative reference to [I-D.ietf-ippm-ioam-data], since PoT gives over IOAM explicitly, and that exists.
* Optionally, an Informative reference to draft-ietf-sfc-ioam-nsh, since that’s really one out of many ways to carry IOAM over NSH, but separated by document indirection. This does not exist but can be added.

From draft-ietf-sfc-ioam-nsh:
* Optionally, an Informative reference to draft-ietf-sfc-proof-of-transit, since that’s one out of many applications. This does not exist but can be added.

Thoughts?

Best,

Carlos.

2020/03/24 午後5:10、Joel M. Halpern <[email-masked]<mailto:[email-masked]>>のメール:

Carlos, it sounds like there should probably be a normative reference from draft-ietf-sfc-proof of transit to draft-ietf-sfc-ioam-nsh? Possibly in the same sentence that refers to draft-ietf-ippm-ioam-data?

Yours,
Joel

2020/03/24 午後4:48、Greg Mirsky <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>のメール:

Hi Joel,

Regards,
Greg

On Tue, Mar 24, 2020 at 1:42 PM Joel M.. Halpern <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

   Regarding the information carriage, the PoT document points to the
   IOAM
   document.
   https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-08#section-4.5
   gives the format (and ways to have other formats if needed.)

   Yours,
   Joel

   On 3/24/2020 4:26 PM, Greg Mirsky wrote:
   > <fbrockne=[email-masked]<mailto:fbrockne=[email-masked]>
   Diego R. Lopez
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     MARTIN <[email-masked]<mailto:[email-masked]>
   >     <mailto:[email-masked] <mailto:[email-masked]>>>;
   Tal Mizrahi <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>
   >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     *From:* Alejandro Aguado FI <[email-masked]<mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <mailto:[email-masked] <mailto:[email-masked]>>>;
   Tal Mizrahi <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>
   >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     (shwethab) ([email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]>
   >     *Cc: *"[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   <mailto:[email-masked] <mailto:[email-masked]>>>,
   "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     (shwethab) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     Mizrahi <[email-masked]<mailto:[email-masked]>
   >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   <mailto:[email-masked] <mailto:[email-masked]>>;
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     (fbrockne) <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   >     <mailto:[email-masked] <mailto:[email-masked]>>>;
   Tal Mizrahi <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>
   >     *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
   <mailto:[email-masked]>>
   > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 24 Mar 2020 17:24:50 -0400

I think we all agree that draft-ietf-sfc-proof-of-transit requires the 
normative reference to draft-ietf-ippm-ioam-data.

Regarding a reference from draft-ietf-sfc-proof-of-transit to 
draft-ietf-sfc-ioam-nsh, I think we agree that it is needed.  The 
question then is normative or informative.  If we use the usual IETF 
rule that there has to be a defined normative way to interoperably 
implement a protocol spec (with other options allowed), my inclination 
is that the reference should be normative.

Regarding the informative reference in the other direction from 
draft-ietf-sfc-ioam-nsh to draft-ietf-sfc-proof-of-transit, while I 
personally like the idea, that is up to you / the working group.

Yours,
Joel

On 3/24/2020 5:20 PM, Carlos Pignataro (cpignata) wrote:
> * Optionally, an Informative reference to draft-ietf-sfc-ioam-nsh, since 
> that’s really one out of many ways to carry IOAM over NSH, but separated 
> by document indirection. This does not exist but can be added.
> 
> * Optionally, an Informative reference to 
> draft-ietf-sfc-proof-of-transit, since that’s one out of many 
> applications. This does not exist but can be added.
> 
> Thoughts?
> 
> Best,
> 
> Carlos.
> 
>>>> 2020/03/24 午後4:48、Greg Mirsky <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>>のメール:
>>>>
>>>> Hi Joel,
>>>> carries POT-related information but it does not define how the 
>>>> element to be carried in case of NSH encapsulation. And that is what 
>>>> I was asking, apologies for not being clear in my first note.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Tue, Mar 24, 2020 at 1:42 PM Joel M.. Halpern 
>>>> <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>    > Hi Frank,
>>>>    > thank you for reminding us about this important work, indeed we
>>>>    should
>>>>    > complete it. I've reviewed the draft and have several questions.
>>>>    Please
>>>>    > kindly consider:
>>>>    >
>>>>    >   * I couldn't find information where, relative to NSH, RND and
>>>>    CML are
>>>>    >     transported
>>>>    >   * for YANG data models using "reference" is strongly
>>>>    encouraged as it
>>>>    >     provides a pointer to the specification. Since the POT data
>>>>    model is
>>>>    >     in the same document as the POT specification, listing the
>>>>    >     appropriate section should suffice
>>>>    >
>>>>    > Regards,
>>>>    > Greg
>>>>    >
>>>>    > On Thu, Mar 19, 2020 at 6:45 AM Frank Brockners (fbrockne)
>>>>    > <fbrockne=[email-masked] 
>>>> <mailto:fbrockne=[email-masked]>
>>>>    > <mailto:[email-masked]
>>>>    >
>>>>    >     Dear SFC WG,____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     It’s been a while since we posted
>>>>    draft-ietf-sfc-proof-of-transit-04
>>>>    >     which addressed all known comments – see below.
>>>>    >     I’ve not seen any more recent comments or questions come up
>>>>    – and
>>>>    >     we’ve been through quite a few discussions and reviews of this
>>>>    >     document already.____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Thus the question: Are we ready for WG LC?____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Thanks, Frank____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     *From:* Frank Brockners (fbrockne)
>>>>    >     *Sent:* Donnerstag, 21. November 2019 08:21
>>>>    >     *To:* Alejandro Aguado FI <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>    Diego R. Lopez
>>>>    >     <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>
>>>>    >     MARTIN <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     Bhandari (shwethab) <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>    >     <mailto:[email-masked]
>>>>    <mailto:[email-masked]>>>
>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    >     *Subject:* RE: PoT review/comments____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     We’ve just posted revision -04 of
>>>>    draft-ietf-sfc-proof-of-transit
>>>>    >     which now includes support for OPOT configuration in the
>>>>    yang model;____
>>>>    >
>>>>    >     see section 5.2.3 in
>>>>    > https://www.ietf.org/id/draft-ietf-sfc-proof-of-transit-04.txt. 
>>>> ____
>>>>    >
>>>>    >     The main addition is a grouping opot-profile, which adds
>>>>    upstream
>>>>    >     and downstream masks that OPOT requires.____
>>>>    >
>>>>    >     Thanks to Alejandro for suggesting these updates.____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     This fixes the last “known issue” in
>>>>    >     draft-ietf-sfc-proof-of-transit. It would be great if you
>>>>    could give
>>>>    >     the document another careful read through.
>>>>    >     Are we ready for WGLC?____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Thanks, Frank____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     *From:* Alejandro Aguado FI <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>    >     *Sent:* Donnerstag, 12. September 2019 15:40
>>>>    >     *To:* Diego R. Lopez <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>
>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]> 
>>>>    >     ALEJANDRO AGUADO MARTIN
>>>>    >     <mailto:[email-masked]
>>>>    >     Bhandari (shwethab) <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>    >     <mailto:[email-masked]
>>>>    <mailto:[email-masked]>>>
>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    >     *Subject:* Re: PoT review/comments____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Hi Shwetha,____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Yes, I think it is a good idea. From your points, the second
>>>>    one is
>>>>    >     a bit confusing to me... But I do not fully remember how the
>>>>    model
>>>>    >     was structured, so I need to revise the document.____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Give me a day or two to explore again the model, and either we
>>>>    >     exchange few emails with proposals for the extension, or we can
>>>>    >     organise a quick call during next week to close a final
>>>>    proposal to
>>>>    >     share with other contributors.____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Thanks!____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     Best,____
>>>>    >
>>>>    >     Alejandro____
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     __ __
>>>>    >
>>>>    >     El 12 de septiembre de 2019 a las 8:52:44, Shwetha Bhandari
>>>>    >     (shwethab) ([email-masked] <mailto:[email-masked]> 
>>>>    >     escribió:____
>>>>    >
>>>>    >     Hi Alejandro, Diego,____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Since you added extension to do OPoT, should we extend the
>>>>    model in
>>>>    >     draft-ietf-sfc-proof-of-transit to enable OPoT and any
>>>>    parameters
>>>>    >     required for it  shared masks per link. If yes my proposal
>>>>    will be
>>>>    >     to:____
>>>>    >
>>>>    >      1. Augment existing pot-profile with fields to Enable OPoT
>>>>    and a
>>>>    >         cipher scheme if needed.____
>>>>    >      2. Separate container in the model to define a map of (Node
>>>>    >         link/interface, mask) to distribute pair wise masks. For
>>>>    e.g.
>>>>    >         Node link/interface identifier can be UUID as defined in
>>>>    rfc8348
>>>>    >         Or____
>>>>    >      3. Masks can be part of pot-profile.____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     What do you think about revising the model with this?____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Thanks,____
>>>>    >
>>>>    >     Shwetha____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     *From: *"Frank Brockners (fbrockne)" <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>    >     *Date: *Wednesday, September 11, 2019 at 2:34 PM
>>>>    >     *To: *ALEJANDRO AGUADO MARTIN
>>>>    >     <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     Lopez" <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <cpignata@cisco..com <mailto:[email-masked]
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>>    >     <[email-masked] <mailto:[email-masked]>
>>>>    >     *Cc: *"[email-masked] <mailto:[email-masked]> 
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>>    "[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] 
>>>> <mailto:[email-masked]>
>>>>    >     *Subject: *RE: PoT review/comments____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Hi Alejandro,____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Thanks again for the review. Your comments have been
>>>>    integrated into
>>>>    >     draft-ietf-sfc-proof-of-transit-03 which just got posted.____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Cheers, Frank____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     *From:*Frank Brockners (fbrockne)
>>>>    >     *Sent:* Montag, 27. Mai 2019 18:18
>>>>    >     *To:* ALEJANDRO AGUADO MARTIN
>>>>    >     <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>
>>>>    >     (shwethab) <[email-masked] <mailto:[email-masked]> 
>>>>    >     Mizrahi <[email-masked] 
>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>
>>>>    >     *Subject:* RE: PoT review/comments____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Hi Alejandro,____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Many thanks for the comments – and sorry for the delay –
>>>>    >     unfortunately your email somehow got dropped from my todo list.
>>>>    >     Please see inline…____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     (cc’ing the list as well).____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     *From:*ALEJANDRO AGUADO MARTIN
>>>>    >     <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     *Sent:* Montag, 15. April 2019 17:27
>>>>    >     *To:* Diego R. Lopez <[email-masked] 
>>>>    >     <mailto:[email-masked]
>>>>    >     <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>
>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]> 
>>>>    >     Bhandari (shwethab) <[email-masked] 
>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>>>>    >     <mailto:[email-masked]
>>>>    <mailto:[email-masked]>>>
>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> 
>>>>    >     *Subject:* PoT review/comments____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Dear all,____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     I gave a quick review to the PoT document. Some comments:____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     - I read “The non-constant coefficients are used to 
>>>> generate the
>>>>    >     Lagrange Polynomial Constants (LPC).” As far as I
>>>>    understood, the
>>>>    >     points assigned to each node (Xi) are the ones used for
>>>>    generating
>>>>    >     the LPCi, aren’t they?____
>>>>    >
>>>>    >     */…FB: Good catch. The LPCs are of course computed using (x_i,
>>>>    >     y_i)./*____
>>>>    >
>>>>    >     - If we go for including the YANG in the current document
>>>>    (which I
>>>>    >     agree), parameters should be described before the yang
>>>>    definition,
>>>>    >     and maybe it would be helpful to have the yang tree (see the
>>>>    current
>>>>    >     version attached).____
>>>>    >
>>>>    >     */…FB: Thanks. IMHO it makes sense to keep the YANG model 
>>>> in the
>>>>    >     current doc, given that the model and the description go 
>>>> hand in
>>>>    >     hand. We can of course also include the yang tree to make
>>>>    reading
>>>>    >     easier. This is consistent with other documents which
>>>>    specify YANG
>>>>    >     models./*____
>>>>    >
>>>>    >     - I include in the attached file few questions about naming
>>>>    of some
>>>>    >     parameters.____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */…FB:
>>>>    >     - naming F_i(x_i, y_i) – I agree that a better name could be
>>>>    used.
>>>>    >     The only potential concern would be that the open source
>>>>    >     implementation in OpenDaylight uses this naming – changing
>>>>    it might
>>>>    >     lead to confusion.. We can start with adding a comment to make
>>>>    >     things clearer./*____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */- secret key – this is the constant part of the first
>>>>    polynomial
>>>>    >     which serves as the secret – and which is re-retrieved.
>>>>    Again, we
>>>>    >     can update the description to make things clearer./*____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */- size of the random number: This is unrelated to OPOT.
>>>>    The random
>>>>    >     number is to uniquely identify a packet. There is a trade-off
>>>>    >     between the size of the random number and how often you need to
>>>>    >     re-key your system. At high speeds, the random number – which
>>>>    >     identifies a particular packet – is used up quite quickly if
>>>>    it is
>>>>    >     only 32-bit wide. See section 4
>>>>    > 
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */- number of profiles: For a deployment which is expected
>>>>    to renew
>>>>    >     keys every now and then (e.g. you run with 32-bit random
>>>>    numbers at
>>>>    >     reasonably high speeds), you need at least 2 profiles – an
>>>>    active
>>>>    >     one and one that you can activate once you run out of random
>>>>    numbers
>>>>    >     (which is what the encapsulating node would decide).. /*____
>>>>    >
>>>>    >     - I have checked some of the existing YANG files within the
>>>>    IETF to
>>>>    >     see in which it would be helpful to include. From the (not
>>>>    so) old
>>>>    >     OpenFlow, I assume that one match is necessary (for 
>>>> identify the
>>>>    >     iOAM/PoT header) whilst the source node can use any existing
>>>>    match
>>>>    >     field to identify packets where to apply the PoT scheme. In
>>>>    terms of
>>>>    >     actions, I would say that two may be required: for any node, an
>>>>    >     update-pot is necessary, while the verifier would need a
>>>>    verify-pot
>>>>    >     type of action, that would ideally either remove the header
>>>>    or drop
>>>>    >     the packet if fails (I do not know if you are thinking in more
>>>>    >     complex scenarios).____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */…FB: From an OF perspective, that sounds feasible.. That
>>>>    said, we
>>>>    >     probably want to avoid making the spec specific to a
>>>>    technology like
>>>>    >     OF, hence would suggest that we don’t specify such a 
>>>> behavior as
>>>>    >     part of this document./*____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     - For this last point, I have seen the definitions within
>>>>    >     draft-asechoud-rtgwg-qos-model-08, where matched could map
>>>>    (if I am
>>>>    >     not wrong) to classifiers/filters, and actions to actions. I
>>>>    send
>>>>    >     you the models in a zip file. In this sense the model to be
>>>>    defined
>>>>    >     in the PoT shall be an augment of the models defined in that
>>>>    >     document. I have not done a very deep revision on the model,
>>>>    but I
>>>>    >     think it could fit there. If you have check this or other
>>>>    models,
>>>>    >     let me know so I could also help.____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */…FB: Per my note above: In order to keep POT generic and
>>>>    not link
>>>>    >     it to a particular classification mechanism, I’d prefer to
>>>>    keep the
>>>>    >     classification question as out of scope for the current
>>>>    document.
>>>>    >     That way it can also apply to technologies which come with
>>>>    their own
>>>>    >     way to classify – and which might fully decouple the tunneling
>>>>    >     aspects from the classification aspects. /*____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Thanks a lot and sorry for such long email.____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     */..FB: Thanks again for all your comments. We’ll get them
>>>>    included
>>>>    >     in the next revision. /*____
>>>>    >
>>>>    >     *//*____
>>>>    >
>>>>    >     */Cheers, Frank/*____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     Best,____
>>>>    >
>>>>    >     Alejandro____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    >     ____
>>>>    >
>>>>    > 
>>>>    >
>>>>    >
>>>>    >     Este mensaje y sus adjuntos se dirigen exclusivamente a su
>>>>    >     destinatario, puede contener información privilegiada o
>>>>    confidencial
>>>>    >     y es para uso exclusivo de la persona o entidad de destino.
>>>>    Si no es
>>>>    >     usted. el destinatario indicado, queda notificado de que la
>>>>    lectura,
>>>>    >     utilización, divulgación y/o copia sin autorización puede estar
>>>>    >     prohibida en virtud de la legislación vigente. Si ha
>>>>    recibido este
>>>>    >     mensaje por error, le rogamos que nos lo comunique
>>>>    inmediatamente
>>>>    >     por esta misma vía y proceda a su destrucción.
>>>>    >
>>>>    >     The information contained in this transmission is 
>>>> privileged and
>>>>    >     confidential information intended only for the use of the
>>>>    individual
>>>>    >     or entity named above. If the reader of this message is not the
>>>>    >     intended recipient, you are hereby notified that any
>>>>    dissemination,
>>>>    >     distribution or copying of this communication is strictly
>>>>    >     prohibited. If you have received this transmission in error,
>>>>    do not
>>>>    >     read it. Please immediately reply to the sender that you have
>>>>    >     received this communication in error and then delete it.
>>>>    >
>>>>    >     Esta mensagem e seus anexos se dirigem exclusivamente ao seu
>>>>    >     destinatário, pode conter informação privilegiada ou
>>>>    confidencial e
>>>>    >     é para uso exclusivo da pessoa ou entidade de destino. Se não é
>>>>    >     vossa senhoria o destinatário indicado, fica notificado de 
>>>> que a
>>>>    >     leitura, utilização, divulgação e/ou cópia sem autorização pode
>>>>    >     estar proibida em virtude da legislação vigente. Se recebeu 
>>>> esta
>>>>    >     mensagem por erro, rogamos-lhe que nos o comunique
>>>>    imediatamente por
>>>>    >     esta mesma via e proceda a sua destruição____
>>>>    >
>>>>    >     _______________________________________________
>>>>    >     sfc mailing list
>>>>    > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> 
>>>> <mailto:[email-masked]
>>>>    <mailto:[email-masked]>>
>>>>    > https://www.ietf.org/mailman/listinfo/sfc
>>>>    >
>>>>    >
>>>>    > _______________________________________________
>>>>    > sfc mailing list
>>>>    > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>    > https://www.ietf.org/mailman/listinfo/sfc
>>>>    >
>>>>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 24 Mar 2020 21:37:50 +0000

Hi, Joel,

> 2020/03/24 午後5:24、Joel M. Halpern <[email-masked]>のメール:
> 
> I think we all agree that draft-ietf-sfc-proof-of-transit requires the normative reference to draft-ietf-ippm-ioam-data.

I agree. That seems clear, I was laying it out for completeness.

> 
> Regarding a reference from draft-ietf-sfc-proof-of-transit to draft-ietf-sfc-ioam-nsh, I think we agree that it is needed.  The question then is normative or informative.  If we use the usual IETF rule that there has to be a defined normative way to interoperably implement a protocol spec (with other options allowed), my inclination is that the reference should be normative.

Similarly, I think the document is improved if it is added.

In regards to Normative or Informative, my initial thinking was the latter. However, I believe either option can be genuinely argued and I am OK either way.

I thought of Informative because PoT can be understood without IOAM-over-NSH and, strictly, the technology of draft-ietf-sfc-ioam-nsh is not necessary to implement. We can easily have PoT in IOAM over something-other-than-NSH. This seems to align with <https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/>.

That said, another equally plausible argument is to specify implementable technology all the way down the stack, and make proof-of-transit a stronger RFC. Although, that might imply a normative reference to the NSH RFC itself, etc.

While I tend to slightly favor Informative, I see the other angle and I’m happy to support Normative if it is the WG’s preference.

> 
> Regarding the informative reference in the other direction from draft-ietf-sfc-ioam-nsh to draft-ietf-sfc-proof-of-transit, while I personally like the idea, that is up to you / the working group.
> 

I like that idea as it provides a bit more context information. I believe we should add this other Informative one.

Best,

Carlos.

>>> 2020/03/24 午後5:10、Joel M. Halpern <[email-masked] <mailto:[email-masked]>>のメール:
>>> 
>>>>> 2020/03/24 午後4:48、Greg Mirsky <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>のメール:
>>>>> 
>>>>> Hi Joel,
>>>>>    > <fbrockne=[email-masked] <mailto:fbrockne=[email-masked]>
>>>>>    >     *To:* Alejandro Aguado FI <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     Bhandari (shwethab) <[email-masked] <mailto:[email-masked]>
>>>>>    Tal Mizrahi <[email-masked] <mailto:[email-masked]>
>>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     *From:* Alejandro Aguado FI <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     Bhandari (shwethab) <[email-masked] <mailto:[email-masked]>
>>>>>    Tal Mizrahi <[email-masked] <mailto:[email-masked]>
>>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     (shwethab) ([email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     *From: *"Frank Brockners (fbrockne)" <[email-masked] <mailto:[email-masked]>
>>>>>    >     Lopez" <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]>
>>>>>    >     *Cc: *"[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     (shwethab) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     Mizrahi <[email-masked] <mailto:[email-masked]>
>>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     (fbrockne) <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    >     Bhandari (shwethab) <[email-masked] <mailto:[email-masked]>
>>>>>    Tal Mizrahi <[email-masked] <mailto:[email-masked]>
>>>>>    >     *Cc:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>>>>    > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
>>>>>    <mailto:[email-masked]>>

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Wed, 25 Mar 2020 20:10:52 +0000

Hi Joel,

I'd second Carlos suggestions and thoughts - but would also appreciate additional thoughts from the WG on how to progress. 

* draft-ietf-sfc-proof-of-transit :
   - adding a normative reference to draft-ietf-ippm-ioam-data is a no brainer and an obvious edit
   - given that POT can be used with a variety of transports, we're best served if we mention at least one example.
     draft-ietf-sfc-ioam-nsh is the obvious example, but others could apply as well. As such, an informative reference might be the better choice IMHO.
     Much like Carlos, I'm happy to also use a normative reference if others feel strongly about it.

* draft-ietf-sfc-ioam-nsh
   - we can add a short section mentioning that for use-cases that require checking proof of transit in an NSH deployment, POT could be leveraged.
     In this context we can add an informative reference to draft-ietf-sfc-proof-of-transit.

Thanks, Frank

> -----Original Message-----
> From: sfc <[email-masked]> On Behalf Of Carlos Pignataro (cpignata)
> Sent: Dienstag, 24. März 2020 22:38
> To: Joel M. Halpern <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE:
> PoT review/comments)
> 
> Hi, Joel,
> 
> > Regarding a reference from draft-ietf-sfc-proof-of-transit to draft-ietf-sfc-
> ioam-nsh, I think we agree that it is needed.  The question then is normative or
> informative.  If we use the usual IETF rule that there has to be a defined
> normative way to interoperably implement a protocol spec (with other options
> allowed), my inclination is that the reference should be normative.
> 
> In regards to Normative or Informative, my initial thinking was the latter.
> However, I believe either option can be genuinely argued and I am OK either
> way.
> 
> I thought of Informative because PoT can be understood without IOAM-over-
> NSH and, strictly, the technology of draft-ietf-sfc-ioam-nsh is not necessary to
> implement. We can easily have PoT in IOAM over something-other-than-NSH.
> This seems to align with
> <https://www.ietf.org/about/groups/iesg/statements/normative-informative-
> references/>.
> 
> That said, another equally plausible argument is to specify implementable
> technology all the way down the stack, and make proof-of-transit a stronger
> RFC. Although, that might imply a normative reference to the NSH RFC itself,
> etc.
> 
> While I tend to slightly favor Informative, I see the other angle and I’m happy to
> support Normative if it is the WG’s preference.
> 
> >
> > Regarding the informative reference in the other direction from draft-ietf-sfc-
> ioam-nsh to draft-ietf-sfc-proof-of-transit, while I personally like the idea, that
> is up to you / the working group.
> >
> 
> >> * Optionally, an Informative reference to draft-ietf-sfc-ioam-nsh, since that’s
> really one out of many ways to carry IOAM over NSH, but separated by
> document indirection. This does not exist but can be added.
> >> * Optionally, an Informative reference to draft-ietf-sfc-proof-of-transit, since
> that’s one out of many applications. This does not exist but can be added.
> >> Thoughts?
> >> Best,
> >> Carlos.
> >>> Carlos, it sounds like there should probably be a normative reference from
> draft-ietf-sfc-proof of transit to draft-ietf-sfc-ioam-nsh? Possibly in the same
> sentence that refers to draft-ietf-ippm-ioam-data?
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>>>    traffic through a specific, user-defined path.  This document
> >>>> defines Explaining how this document is applicable to various traffic-
> steering technologies.
> >>>> Section 3 then explains:
> draft describes the format of the informational element that carries POT-related
> information but it does not define how the element to be carried in case of NSH
> encapsulation. And that is what I was asking, apologies for not being clear in my
> first note.
> >>>>>
> >>>>> Regards,
> >>>>> Greg
> >>>>>
> <[email-masked]<mailto:[email-masked]>
> >>>>>    >     MARTIN
> >>>>>    >     *To:* Diego R. Lopez
> >>>>>    >     *To:* Diego R. Lopez