Subject: [sfc] AD review of draft-ietf-sfc-nsh-18

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Aug 2017 18:58:23 -0400

As is customary, I have done my AD review of draft-ietf-sfc-nsh-18.  First,
I would like to thank the editors, Carlos, Uri, and Paul, as well as the
many contributors for their work on this document.  It has improved
substantially.

I do have a few minor comments from my review.  They are below.  I will
proceed to ask for an IETF Last Call now and schedule this draft for Aug
31; for that telechat date, I will require a very active shepherd as well
as editors.

Please do SUBMIT the latest editor's version of this draft ASAP.  Version
numbers are cheap and it is much better for reviewers to see the latest
version. This must be the process going forward to avoid the same points
being brought up multiple times.

1) As Acee already noted, receivers of unassigned flags MUST ignore the
value.  There are a couple places to fix this.

2) Given the consensus in NVO3 and that VXLAN-GPE will be progressed as an
informational document described an alternative that was not selected for
standardization, I would prefer a different example in Sec 6.1 Table 1.

3) In Sec 7.1, there is a sentence "In some cases they may terminate, and
be able to inspect encrypted traffic."  Unless there is a strong technical
need to point this out, I would pick a different example.  There is a great
deal of current controversy and discussion happening in TLS currently - and
this is likely to trigger that discussion unnecessarily.

4) I am happy to see that IEEE (
https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries)
is now showing the EtherType 0x894F as referring to this draft.  Thanks!

Regards,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 12 Aug 2017 01:09:52 +0000

Thanks, Alia. Please see inline.

On Aug 11, 2017, at 6:58 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

As is customary, I have done my AD review of draft-ietf-sfc-nsh-18.  First, I would like to thank the editors, Carlos, Uri, and Paul, as well as the many contributors for their work on this document.  It has improved substantially.

I do have a few minor comments from my review.  They are below.  I will proceed to ask for an IETF Last Call now and schedule this draft for Aug 31; for that telechat date, I will require a very active shepherd as well as editors.

Please do SUBMIT the latest editor's version of this draft ASAP.  Version numbers are cheap and it is much better for reviewers to see the latest version. This must be the process going forward to avoid the same points being brought up multiple times.

Sounds good.

1) As Acee already noted, receivers of unassigned flags MUST ignore the value.  There are a couple places to fix this.

Agreed. Done.

2) Given the consensus in NVO3 and that VXLAN-GPE will be progressed as an informational document described an alternative that was not selected for standardization, I would prefer a different example in Sec 6.1 Table 1.

This is just an example, non normative, non-binging, and list VXLAN-GPE along with GRE and Ethernet. What would you prefer the document uses?

3) In Sec 7.1, there is a sentence "In some cases they may terminate, and be able to inspect encrypted traffic."  Unless there is a strong technical need to point this out, I would pick a different example.  There is a great deal of current controversy and discussion happening in TLS currently - and this is likely to trigger that discussion unnecessarily.

Ack. Gone.

4) I am happy to see that IEEE (https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries) is now showing the EtherType 0x894F as referring to this draft.  Thanks!

Anytime :-)

Thanks!

Carlos.

Regards,
Alia

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

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Aug 2017 21:12:20 -0400

On Fri, Aug 11, 2017 at 9:09 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> On Aug 11, 2017, at 6:58 PM, Alia Atlas <[email-masked]> wrote:
>
> As is customary, I have done my AD review of draft-ietf-sfc-nsh-18.
> First, I would like to thank the editors, Carlos, Uri, and Paul, as well as
> the many contributors for their work on this document.  It has improved
> substantially.
>
> This is just an example, non normative, non-binging, and list VXLAN-GPE
> along with GRE and Ethernet. What would you prefer the document uses?
>

Geneve?  MPLS? UDP?

Something Standards Track please.

Thanks,
Alia

> 4) I am happy to see that IEEE (https://regauth.standards.
> ieee.org/standards-ra-web/pub/view.html#registries) is now showing the
> EtherType 0x894F as referring to this draft.  Thanks!
>
>
> Anytime :-)
>
> Thanks!
>
> Carlos.
>
>
> Regards,
> Alia
>
> [email-masked]
> Carlos Pignataro, [email-masked]
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 12 Aug 2017 01:19:26 +0000

On Aug 11, 2017, at 9:12 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Aug 11, 2017 at 9:09 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Alia. Please see inline.

Sounds good.

Agreed. Done.

Geneve?  MPLS? UDP?

I think that would give the wrong impression that SFC can run only atop Standards Track IETF technology.

The document currently lists: GRE, Standards Track. UDP in Table 3, Standards Track. VXLAN-GPE, Informational. And Ethernet. Sounds like a diverse mix.

If you insist, I could add more rows to the table to also be more inclusive in addition to diverse? I can also add more IPv6 NHs if so?

Thanks!

Carlos.

Thanks,
Alia

Ack. Gone.

Anytime :-)

Thanks!

Carlos.

Regards,
Alia

—

—

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Aug 2017 21:23:06 -0400

On Fri, Aug 11, 2017 at 9:19 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

>
> On Aug 11, 2017, at 9:12 PM, Alia Atlas <[email-masked]> wrote:
>
>
>
>> 2) Given the consensus in NVO3 and that VXLAN-GPE will be progressed as
>> an informational document described an alternative that was not selected
>> for standardization, I would prefer a different example in Sec 6.1 Table 1.
>>
>>
> The document currently lists: GRE, Standards Track. UDP in Table 3,
> Standards Track. VXLAN-GPE, Informational. And Ethernet. Sounds like a
> diverse mix.
>

VXLAN-GPE will be Informational - in the sense of an alternative considered
and not taken.

There is no reason to fail to respect the consensus in NVO3.  If you want
to toss in VXLAN, that'd be fine.

> If you insist, I could add more rows to the table to also be more
> inclusive in addition to diverse? I can also add more IPv6 NHs if so?
>
> Thanks!
>
> Carlos.
>
> Thanks,
> Alia
>
>
>> 4) I am happy to see that IEEE (https://regauth.standards.iee
>> e.org/standards-ra-web/pub/view.html#registries) is now showing the
>> *“Sometimes I use big words that I do not fully understand, to make
>> myself sound more photosynthesis."*
>>
>
> —

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 12 Aug 2017 01:33:47 +0000

> On Aug 11, 2017, at 9:23 PM, Alia Atlas <[email-masked]> wrote:
> 
> 
> 
> On Fri, Aug 11, 2017 at 9:19 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
>> On Fri, Aug 11, 2017 at 9:09 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> VXLAN-GPE will be Informational - in the sense of an alternative considered and not taken.  

Does NSH say that it can only run on Standards-Track transports? I do not believe this spec places any restrictions on the “pedigree” of the tunnel.

> 
> There is no reason to fail to respect the consensus in NVO3.  

I fail to see how this is disrespecting consensus in the NVO3 WG.

The Transports, as far as NSH are concerned, are Informative references, non-normative examples (which include IETF standards track technology, non-IETF technology, etc).

There is actual purpose in mentioning technologies that are also not standards track: to show that NSH can actually be deployed on them, independently of the NSH spec.

> If you want to toss in VXLAN, that'd be fine.   
> 

I have not desire to "toss in" tunneling technologies without understand why. 

I am happy to add others as you or the WG see fit.

Thanks,

Carlos.

—