Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jun 2018 10:05:01 -0400

My impression of the conversation in London was that the working group 
was leaning towards keeping both of the proof of transit algorithms.
One because it is very efficient and confirms that each SF has been visited,
and the other because although it is more complex, it verifies order of 
visiting, which is important in a significant subset of cases.

Do folks on the list agree with that direction?

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Jun 2018 18:44:26 +0100

Yes, Joel,

That sounds right as these are different levels of function.

So long as we add the ability to request/control which level of function is
applied to a trace, and so long as we protect that against downgrade attack.

A

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: 05 June 2018 15:05
> To: [email-masked]
> Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Elzur, Uri" <[email-masked]>
Date: Wed, 6 Jun 2018 18:23:27 +0000

few questions:

1) assume this is not positioned as MANDATORY but rather OPTIONAL, status of the I-D is EXPERIMENTAL
2) two mechanisms (consulting the minutes) is low computation and NOT in -order or high computational and in-order?
3) for NSH - will this be packaged in a TLV? 

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, June 5, 2018 7:05 AM
To: [email-masked]
Subject: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms

My impression of the conversation in London was that the working group was leaning towards keeping both of the proof of transit algorithms.
One because it is very efficient and confirms that each SF has been visited, and the other because although it is more complex, it verifies order of visiting, which is important in a significant subset of cases.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jun 2018 14:36:56 -0400

Not quite Uri.  Making something PS does not make it mandatory. 
Customers decide which RFCs to ask for in products.  Vendors decide 
which RFCs to implement.  What Proposed Standard means is that if you 
want to implement this beahviro in the agreed fashion, this is how to do it.

Experimental means that the IETF is not confident that the defined thing 
is useful / the right way to meet the need / harmless / ...

There are clearly additional aspects such as encoding still to be 
specified before we consider declaring this work complete.

The PoT work seems to lend itself to a TLV.  There may be some desire to 
align with whatever we conclude on the IOAM format.

Yours,
Joel

---

From: "Elzur, Uri" <[email-masked]>
Date: Wed, 6 Jun 2018 18:46:26 +0000

Hi Joel

Tanks I think we are aligned, sorry if my wording choice was confusing

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, June 6, 2018 11:37 AM
To: Elzur, Uri <[email-masked]>; [email-masked]
Subject: Re: [sfc] draft-ietf-sfc-proof-of-transit - mechanisms

Not quite Uri.  Making something PS does not make it mandatory. 
Customers decide which RFCs to ask for in products.  Vendors decide which RFCs to implement.  What Proposed Standard means is that if you want to implement this beahviro in the agreed fashion, this is how to do it.

Experimental means that the IETF is not confident that the defined thing is useful / the right way to meet the need / harmless / ...

There are clearly additional aspects such as encoding still to be specified before we consider declaring this work complete.

The PoT work seems to lend itself to a TLV.  There may be some desire to align with whatever we conclude on the IOAM format.

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 9 Jun 2018 09:23:33 -0700

Hi Joel, et. al,
I think that, as with any solution proposal, we need to check it against
the use case(s) and the requirements that characterize these cases. I don't
see these being discussed in the draft. As you've pointed, the draft
addresses two cases:

   - verification that pre-defined set of nodes was visited;
   - verification that pre-defined ordered set of nodes was traversed in
   the expected order.

What are the use cases for each solution and are both required or only the
latter, as the stronger and complete, has a practical use?
What being verified - traversing SF or SFF?

The list will grow as we look into the use cases.

And one more, the proposed solution is only one of many algorithms. I
believe it will be future proof to allow for other algos to be used.

Regards,
Greg

On Tue, Jun 5, 2018 at 7:05 AM, Joel M. Halpern <[email-masked]> wrote:

> My impression of the conversation in London was that the working group was
> leaning towards keeping both of the proof of transit algorithms.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 26 Jun 2018 05:25:38 +0000

Joel,

I agree with the direction you describe below, and for completeness I do not support building use case documents and requirement documents. The reference from RFC 8300 suffices.

Thanks,

— Carlos Pignataro

On Jun 9, 2018, at 12:23 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joel, et. al,
I think that, as with any solution proposal, we need to check it against the use case(s) and the requirements that characterize these cases. I don't see these being discussed in the draft. As you've pointed, the draft addresses two cases:

  *   verification that pre-defined set of nodes was visited;
  *   verification that pre-defined ordered set of nodes was traversed in the expected order.

What are the use cases for each solution and are both required or only the latter, as the stronger and complete, has a practical use?
What being verified - traversing SF or SFF?

And one more, the proposed solution is only one of many algorithms. I believe it will be future proof to allow for other algos to be used.

Regards,
Greg

On Tue, Jun 5, 2018 at 7:05 AM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
My impression of the conversation in London was that the working group was leaning towards keeping both of the proof of transit algorithms.
One because it is very efficient and confirms that each SF has been visited,
and the other because although it is more complex, it verifies order of visiting, which is important in a significant subset of cases.

Yours,
Joel

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc