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

["Joel M. Halpern" <[e-mail]>]

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:
> 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
>