Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

[Stewart Bryant <[e-mail]>]

I can see the utility in that case, but I think that we need to set that 
expectation with the reader of the text.

Stewart


On 10/01/2017 19:19, Frank Brockners (fbrockne) wrote:
>
> We probably need to differentiate things based on the use case, i.e.
>
> 1) *prove* in a secure way that a packet visited a particular set of nodes
>
> 2) *provide some hint* (e.g. to help operations) whether a packet 
> visited a particular set of nodes
>
> The POT mechanism in draft-brockners-proof-of-transit-02.txt is very 
> much targeted at 1) – and the target box to perform these mechanisms 
> is probably more like a firewall or similar, which would have the 
> capabilities to do a bunch of operations on a packet – and differ from 
> a core/backbone router.
>
> Frank
>
> *From:*OPSAWG [mailto:[e-mail]] *On Behalf Of *Stewart 
> Bryant
> *Sent:* Dienstag, 10. Januar 2017 20:10
> *To:* [e-mail]
> *Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> I share that concern.
>
> I think that for this to fly, there needs to be a hardware friendly 
> version.
>
> It also seems to me that lots of applications would be satisfied with 
> an approach that assumes that all routers are honest, perhaps simply 
> setting a bit in a bit field, reserving the ultra-cautious check for 
> special faults or special operating environments.
>
> Stewart
>
> On 10/01/2017 17:52, Linda Dunbar wrote:
>
>     Frank,
>
>     Your suggested approach requires egress node to do the computation
>     of “(Secret +RND) mod prime” and perform the comparison for every
>     packet. For a node with hundreds of ports and each with 10G-100G
>     capacity, the computation & comparison would be very heavy.
>
>     Linda
>
>     *From:*Frank Brockners (fbrockne) [mailto:[e-mail]]
>     *Sent:* 2017年1月3日7:43
>     *To:* Linda Dunbar <[e-mail]>
>     <mailto:[e-mail]>; Ram Krishnan
>     <[e-mail]> <mailto:[e-mail]>; Zhoutianran
>     <[e-mail]> <mailto:[e-mail]>;
>     [e-mail] <mailto:[e-mail]>
>     *Subject:* RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
>     drafts
>
>     Hi Linda,
>
>     thanks for supporting
>     https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt.
>
>     On
>     https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt:
>     Could you elaborate a bit more why you believe that the approach
>     would be too complicated for the egress node? All it takes for the
>     verifier node is to perform a “(Secret + RND) mod prime” operation
>     and compare this to the CML number received in the packet (RND and
>     CML are the two numbers carried within the packet).
>
>     Thanks, Frank
>
>     *From:*OPSAWG [mailto:[e-mail]] *On Behalf Of
>     *Linda Dunbar
>     *Sent:* Dienstag, 3. Januar 2017 14:27
>     *To:* Ram Krishnan <[e-mail]
>     <mailto:[e-mail]>>; Zhoutianran <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
>     drafts
>
>     I support WG Adoption of
>     https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
>
>
>     But I don’t support the detailed mechanism described in
>     https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txtto
>     be adopted. I think the approaches described are too complicated
>     for the egress nodes.
>
>     Linda Dunbar
>
>     *From:*OPSAWG [mailto:[e-mail]] *On Behalf Of *Ram
>     Krishnan
>     *Sent:* 2016年12月30日6:41
>     *To:* Zhoutianran <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
>     drafts
>
>     Hi Tianran,
>
>     I can see the new draft playing predominantly a complementary
>     role. I have summarized some of the key areas and also added
>     comments, please see below.
>
>     1)https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
>
>
>     -Complementary role of new draft:
>
>     oMinimizing of In-band Telemetry Header for a specific use case
>     such as latency measurement
>
>     oData export options
>
>     §Summarizing monitoring information to build a scalable solution –
>     for example, alert the central management system only when 99^th
>     percentile queue depth exceeds a high threshold for a flow
>
>     §Flow mirroring
>
>     oService chaining use case (independent and coupled with
>     underlay/overlay) – describes how network monitoring can help in
>     identifying server side issues and pave the way to dynamic
>     resource orchestration to remedy the issue
>
>     2)https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
>
>     -Complementary role of new draft:
>
>     oMinimizing of In-band Telemetry Header format
>
>     oData export options format
>
>     -Comments on above draft:
>
>     oI am surprised to see
>     http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf
>     not being referenced.
>
>     3)https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01
>
>     -Comments on above draft:
>
>     oThe above id focusses on injected probe packets. The new draft is
>     applicable to all packets including injected probe packets.
>
>     4)Mapping in-band telemetry to different transport protocols – new
>     contribution (this could be a separate draft or might be input to
>     be above drafts)
>
>     oComplementary role of new draft:
>
>     §IPSEC use case for WAN and DC (beyond internet connectivity) and
>     mapping
>
>     §VXLAN-GPE/Geneve/NSH mapping
>
>     5)https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt
>
>     -Comments on above draft:
>
>     oOne of the key reasons for packets following a path different
>     from a traffic engineered/service chain path is misconfiguration.
>     With that background,
>
>     §With an administrative domain, practical service verification
>     scheme(s)
>     (https://datatracker.ietf.org/doc/draft-irtf-nfvrg-service-verification/?include_text=)
>     could suffice
>
>     §The elaborate proof of transit scheme suggested in this draft is
>     possibly applicable across administrative domains where it may not
>     be possible to mandate service verification. Additionally, when
>     the path is changed dynamically based on intermediate node state
>     it is not clear how this scheme will work.
>
>     Thanks,
>
>     Ramki
>
>     *From:*Zhoutianran [mailto:[e-mail]
>     <mailto:[e-mail]>]
>     *Sent:* Sunday, December 25, 2016 10:57 PM
>     *To:* ram krishnan <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *Subj**ect:*RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM
>     drafts
>
>     Hi Ramki,
>
>     Thanks for bringing a new I-D to this WG.
>
>     Could you please state the relationship or potential overlay with
>     the In Situ OAM serial I-Ds and also
>     (https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01)?
>
>     Best,
>
>     Tianran
>
>     *From:*OPSAWG [mailto:[e-mail]] *On Behalf Of *ram
>     krishnan
>     *Sent:* Saturday, December 24, 2016 7:09 PM
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
>     I support adoption of these drafts.
>
>     In addition, I would like bring a closely related draft to your
>     attention --
>     https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1
>
>     This draft brings some important contributions in the area of
>     requirements and data formats for
>
>     -IPSEC tunneling
>
>     -Pre-construction/minimizing of Telemetry header
>
>     -Service chaining – benefits beyond the network interconnect
>
>     I was hoping to get this draft out by Seoul timeframe and make it
>     in person, unfortunately couldn’t. Looking forward to discussions
>     and collaboration on this interesting topic.
>
>     Thanks,
>
>     Ramki
>
>     ---------- Forwarded message ----------
>     From: *ram krishnan* <[e-mail]
>     <mailto:[e-mail]>>
>     Date: Fri, Dec 23, 2016 at 1:59 PM
>     Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
>     To: Ram Krishnan <[e-mail] <mailto:[e-mail]>>
>
>     On 12/7/16 01:36, Zhoutianran wrote:
>
>         Hi All,
>
>           
>
>           
>
>           
>
>         In Seoul, we got enough interest on the In Situ OAM work and positive
>
>         response on related drafts.
>
>         So this email starts a formal poll for adoption the following I-Ds.
>
>           
>
>           
>
>           
>
>         ​​
>         <https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt>
>
>         https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
>
>         https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
>
>         https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt
>
>           
>
>           
>
>           
>
>         To be efficient, we have the poll for three I-Ds in one thread. But you
>
>         can give your opinion on each of them. And the result is per I-D.
>
>           
>
>           
>
>           
>
>         The question is:
>
>         Do you think that the WG should adopt all or some of these drafts?
>
>           
>
>           
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean.
>
>
>
>     -- 
>
>     Thanks,
>
>     Ramki
>
>
>
>
>     _______________________________________________
>
>     OPSAWG mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/opsawg
>