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

[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. 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.

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
>