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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>のメール:

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 <[e-mail]<mailto:[e-mail]>> 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:
> 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=[e-mail]<mailto:[e-mail]>
> <mailto:[e-mail]<mailto:[e-mail]>>> 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____
>
>     __ __
>
>     *From:* Frank Brockners (fbrockne)
>     *Sent:* Donnerstag, 21. November 2019 08:21
>     *To:* Alejandro Aguado FI <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Diego R. Lopez
>     <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Carlos Pignataro (cpignata)
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:cpignata@cisco..com>>>; ALEJANDRO AGUADO
>     MARTIN <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Shwetha
>     Bhandari (shwethab) <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     *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 <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Sent:* Donnerstag, 12. September 2019 15:40
>     *To:* Diego R. Lopez <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Carlos Pignataro (cpignata)
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:cpignata@cisco..com>>>; Frank Brockners
>     (fbrockne) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>;
>     ALEJANDRO AGUADO MARTIN <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Shwetha
>     Bhandari (shwethab) <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     *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) ([e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>)
>     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)" <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Date: *Wednesday, September 11, 2019 at 2:34 PM
>     *To: *ALEJANDRO AGUADO MARTIN
>     <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>, "Diego R.
>     Lopez" <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>, Carlos Pignataro
>     <cpignata@cisco..com <mailto:[e-mail]<mailto:[e-mail]>>>, Shwetha bhandari
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:shwethab@cisco..com>>>, Tal Mizrahi
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Cc: *"[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>"
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>, "[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>
>     *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
>     <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Diego R. Lopez
>     <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Carlos Pignataro (cpignata)
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:cpignata@cisco..com>>>; Shwetha Bhandari
>     (shwethab) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Tal
>     Mizrahi <[e-mail]<mailto:tal.mizrahi.phd@gmail..com> <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>
>     *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
>     <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Sent:* Montag, 15. April 2019 17:27
>     *To:* Diego R. Lopez <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Carlos Pignataro (cpignata)
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:cpignata@cisco..com>>>; Frank Brockners
>     (fbrockne) <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>; Shwetha
>     Bhandari (shwethab) <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>; Tal Mizrahi <[e-mail]<mailto:[e-mail]>
>     <mailto:[e-mail]<mailto:[e-mail]>>>
>     *Cc:* [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     *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____
>
>     _______________________________________________
>     sfc mailing list
>     [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     https://www.ietf.org/mailman/listinfo/sfc
>
>
> _______________________________________________
> sfc mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/sfc
>
_______________________________________________
sfc mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sfc