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

["Shwetha Bhandari (shwethab)" <[e-mail]>]

+1 to the below suggestions from Frank and Carlos:

It does make sense to keep/update draft-ietf-sfc-proof-of-transit with:
- normative reference to draft-ietf-ippm-ioam-data
- Example encapsulation with an informative reference to draft-ietf-sfc-ioam-nsh

Thanks,
Shwetha
    
    > -----Original Message-----
    > From: sfc <[e-mail]> On Behalf Of Frank Brockners (fbrockne)
    > Sent: Wed, 25 March 2020 20:11 UTC
    > To: Carlos Pignataro (cpignata) <cpignata=[e-mail]>; Joel
    > M. Halpern <[e-mail]>
    > Cc: [e-mail]
    > Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE:
    > PoT review/comments)
    > 
    > 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 <[e-mail]> On Behalf Of Carlos Pignataro
    > > (cpignata)
    > > Sent: Dienstag, 24. März 2020 22:38
    > > To: Joel M. Halpern <[e-mail]>
    > > Cc: [e-mail]
    > > Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit-04 ready for WGLC? (was RE:
    > > PoT review/comments)
    > >
    > > Hi, Joel,
    > >
    > > > 2020/03/24 午後5:24、Joel M. Halpern <[e-mail]>のメール:
    > > >
    > > > 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-informati
    > > ve-
    > > 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.
    > >
    > > > Yours,
    > > > Joel
    > > >
    > > > On 3/24/2020 5:20 PM, Carlos Pignataro (cpignata) wrote:
    > > >> 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 <[e-mail]
    > > <mailto:[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]> <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]>
    > > <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: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]
    > <mailto:[e-mail]>>>;
    > > >>>>>    Diego R. Lopez
    > > >>>>>    >     <[e-mail]
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail]
    > > >>>>>    <mailto:[e-mail]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[e-mail] <mailto:[e-mail]>
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail] <mailto:cpignata@cisco..com>>>;
    > > >>>>>    ALEJANDRO AGUADO
    > > >>>>>    >     MARTIN
    > >
    > <[e-mail]<mailto:alejandro.aguadomartin.
    > > [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] <mailto:[e-mail]>>>;
    > > >>>>>    Tal Mizrahi <[e-mail]
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail]
    > > >>>>>    <mailto:[e-mail]>>>
    > > >>>>>    >     *Cc:* [e-mail] <mailto:[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]
    > <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]
    > > >>>>>    <mailto:[e-mail]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[e-mail] <mailto:[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] <mailto:[e-mail]>>>;
    > > >>>>>    >     ALEJANDRO AGUADO MARTIN
    > > >>>>>
    > >
    > <[e-mail]<mailto:alejandro.aguadomartin.
    > > [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] <mailto:[e-mail]>>>;
    > > >>>>>    Tal Mizrahi <[e-mail]
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail]
    > > >>>>>    <mailto:[e-mail]>>>
    > > >>>>>    >     *Cc:* [e-mail] <mailto:[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] <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] <mailto:[e-mail]>>>
    > > >>>>>    >     *Date: *Wednesday, September 11, 2019 at 2:34 PM
    > > >>>>>    >     *To: *ALEJANDRO AGUADO MARTIN
    > > >>>>>    >
    > >
    > <[e-mail]<mailto:alejandro.aguadomartin.
    > > [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]
    > > >>>>>    <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:[e-mail] <mailto:shwethab@cisco..com>>>,
    > > >>>>> Tal
    > > Mizrahi
    > > >>>>>    >     <[e-mail]
    > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]
    > > <mailto:[e-mail]>>>
    > > >>>>>    >     *Cc: *"[e-mail] <mailto:[e-mail]>
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail] <mailto:[e-mail]>>"
    > > >>>>>    >     <[e-mail] <mailto:[e-mail]>
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail] <mailto:[e-mail]>>>,
    > > >>>>>    "[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail] <mailto:[e-mail]>>" <[e-mail]
    > > <mailto:[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:alejandro.aguadomartin.
    > > [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]
    > > >>>>>    <mailto:[e-mail]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[e-mail] <mailto:[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] <mailto:[e-mail]>>>; Tal
    > > >>>>>    >     Mizrahi <[e-mail]
    > > <mailto:[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] <mailto:[e-mail]>>;
    > > >>>>> [e-mail] <mailto:[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:alejandro.aguadomar
    > > tin
    > > [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]
    > > >>>>>    <mailto:[e-mail]>>>; Carlos Pignataro
    > (cpignata)
    > > >>>>>    >     <[e-mail] <mailto:[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] <mailto:[e-mail]>>>;
    > > Shwetha
    > > >>>>>    >     Bhandari (shwethab) <[e-mail]
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail] <mailto:[e-mail]>>>;
    > > >>>>>    Tal Mizrahi <[e-mail]
    > > <mailto:[e-mail]>
    > > >>>>>    <mailto:[e-mail]>
    > > >>>>>    >     <mailto:[e-mail]
    > > >>>>>    <mailto:[e-mail]>>>
    > > >>>>>    >     *Cc:* [e-mail] <mailto:[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]
    > > >>>>>    <mailto:[e-mail]>>
    > > >>>>>    > https://www.ietf.org/mailman/listinfo/sfc
    > > >>>>>    >
    > > >>>>>    >
    > > >>>>>    > _______________________________________________
    > > >>>>>    > sfc mailing list
    > > >>>>>    > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
    > > >>>>>    > https://www.ietf.org/mailman/listinfo/sfc
    > > >>>>>    >
    > > >>>>>
    > > >>>>> _______________________________________________
    > > >>>>> sfc mailing list
    > > >>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
    > > >>>>> https://www.ietf.org/mailman/listinfo/sfc
    > >
    > > _______________________________________________
    > > sfc mailing list
    > > [e-mail]
    > > https://www.ietf.org/mailman/listinfo/sfc
    > _______________________________________________
    > sfc mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/sfc