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

[Greg Mirsky <[e-mail]>]

Carlos,
after reading Joel's conditional MUST I've reconsidered my position. I
agree with the text he proposed.

Regards,
Greg

On Wed, Apr 1, 2020 at 4:47 PM Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Greg,
>
> I understood Joel’s reasoning to be different than yours, and different
> his position also (I understood Joel to be OK either way with a preference
> for Normative, and later he gave a suggestion of a conditional MUST, while
> your position seemed to me an absolute MUST, more terminal and inflexible).
>
> For completeness, this was the question I asked you, under the context of
> the IESG note in [1] below:
>
> Is the technology in draft-ietf-sfc-ioam-nsh a “must” for
>> draft-ietf-sfc-proof-of-transit?
>
>
> What do you think?
>
> Best,
>
> Carlos.
>
>
> 2020/04/01 午後7:28、Greg Mirsky <[e-mail]>のメール:
>
> Dear Carlos,
> I believe that Joel has expressed it clearly and I concur with his
> reasoning.
>
> Regards,
> Greg
>
> On Wed, Apr 1, 2020 at 4:13 PM Carlos Pignataro (cpignata) <
> [e-mail]> wrote:
>
>> Dear Greg,
>>
>> This seems to be a rephrase of the previous email, yet I still do not
>> follow the cause-effect in your argument.
>>
>> Normative does not mean “a reference that defines technology within the
>> same Working Group’s documents that can be used”.
>>
>> The definition and clarification statement at [1] says “documents that
>> must be read to understand or implement the technology in the new RFC”. It
>> does not speak to WG charters or.
>>
>> Is the technology in draft-ietf-sfc-ioam-nsh a “must” for
>> draft-ietf-sfc-proof-of-transit? It seems to me that the only “must”
>> technology is ippm-ioam-data. I appreciate that this is also not
>> necessarily a yes/no binary answer...
>>
>> [Again, I am OK either way, for the right reason]
>>
>> Carlos.
>>
>> [1]
>> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
>>
>>
>> > 2020/04/01 午後3:36、Greg Mirsky <[e-mail]>のメール:
>> >
>> > Dear Carlos,
>> > in my previous note I have recognized that POT, as SFC, can be realized
>> using different techniques. But this is SFC WG document and, as I
>> understand the charter of SFC WG, we're defining technologies that use SFC
>> NSH. Hence my conclusion that the reference to draft-ietf-sfc-ioam-nsh
>> should be normative, as that is the only document that defines iOAM
>> encapsulation in NSH. Making the reference informational could be
>> interpreted as suggestion that POT in SFC NSH might be encapsulated not as
>> iOAM but in some other manner. And while that is possible, I don't see a
>> proposal that describes such alternative encapsulation. So, it appears that
>> the WG has agreed that POT in SFC NSH should use encapsulation as defined
>> in draft-ietf-sfc-ioam-nsh.
>> >
>> > Regards,
>> > Greg
>> >
>> > On Wed, Apr 1, 2020 at 12:16 PM Carlos Pignataro (cpignata) <
>> [e-mail]> wrote:
>> > Dear Greg,
>> >
>> > > 2020/04/01 午後2:59、Greg Mirsky <[e-mail]>のメール:
>> > >
>> > > Dear All,
>> > > I agree with Joel that the reference in
>> draft-ietf-sfc-proof-of-transit to draft-ietf-ippm-ioam-data should be
>> normative.
>> >
>> > Great. Everyone seems to be aligned on this point.
>> >
>> >
>> > > I also support the proposal to add in draft-ietf-sfc-proof-of-transit
>> a normative reference to draft-ietf-sfc-ioam-nsh. SFC WG is working on
>> defining SFC that is based on NSH (SFC NSH), and while SFC might be
>> realized using other techniques, draft-ietf-sfc-ioam-nsh is, and likely
>> will remain, the only document that is describing iOAM encapsulation in SFC
>> NSH. Thus, I believe, for SFC WG, implementation of PoT based on iOAM
>> requires implementation of iOAM encapsulation in SFC NSH, as defined in
>> draft-ietf-sfc-ioam-nsh. Hence, the reference must be normative.
>> >
>> >
>> > This logic is flawed in the onset. The main point is that POT can be
>> realized with a variety of transports and technologies and use-cases, one
>> of which is SFC, and then further within SFC one of which is NSH.
>> >
>> > You seem to argue that NSH is somehow in practice the only SFC
>> realization, and because of that the reference “must be normative”.
>> >
>> > I disagree with the premise, but regardless, it does not matter since
>> POT applies to other non-SFC(-non-NSH) technologies. Therefore that
>> since-then logic does not apply.
>> >
>> > Copying the very first sentence of the Abstract:
>> >
>> >    Several technologies such as Traffic Engineering (TE), Service
>> >    Function Chaining (SFC), and policy based routing [...]
>> >
>> >
>> > And now looking at this fragment, I am more convinced that this is one
>> example and as such Informative.
>> >
>> > I would not object to Normative for the right reasons, but the reason
>> above, in my mind, does not follow.
>> >
>> > Thanks,
>> >
>> > Carlos.
>> >
>> >
>> > >
>> > > Regards,
>> > > Greg
>> > >
>> > > On Tue, Mar 24, 2020 at 2:25 PM Joel M. Halpern <[e-mail]>
>> wrote:
>> > > 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:
>> > > > 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:[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:[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:[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:[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:[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
>> >
>>
>>
>