Subject: [nvo3] AD review of draft-ietf-nvo3-use-case-14

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Dec 2016 15:32:11 -0500

[resend with subject]

As is customary, I have done my AD review of draft-ietf-nvo3-use-case-14.
First, I would like to thank the authors - Lucy, Linda, Mehmet, Aldrin, &
Vishwas - for their work on this document.   It has noticeably improved
since the last time I reviewed it.

As part of my review, I do have a few minor comments below that I would
like to see addressed.   I am going to assume that the authors will be
responsive and request an IETF Last Call now - and schedule this document
for the Jan 19 IESG telechat.   I have also requested a Routing Directorate
review.

Minor:

1) Sec 1: "Independent address spaces in individual NVO3 networks such
as MAC, IP, TCP/UDP etc."  I have no idea what you mean by TCP/UDP being an
independent address space.  Please either clarify or remove it.

2) Sec 2:"It also means that the nodes in the infrastructure network (except
   tunnel end point nodes) carry encapsulated NVO3 traffic but not
   aware of the existence of NVO3 networks."
   From discussions on the NVO3 encapsulation, there seem to be some
perspectives that nodes in the infrastructure network may have reasons
(OAM, etc) to be aware of the NVO3 networks.  Can you tone this down to the
following?

 "It also means that the nodes in the infrastructure network (except tunnel
end point nodes) carry encapsulated NVO3 traffic but are not responsible
for decapsulating or encapsulating NVO3 traffic."

3) Sec 4.1:"For the servers equipped with Hypervisor-based virtual
switches, some may
   support VxLAN [RFC7348] encapsulation, some may support NVGRE
   encapsulation [RFC7637], and some may not support any encapsulation."

This should at least mention the existence of the NVO3 encapsulation and
indicate that VxLAN and NVGRE are not standards.  For instance:

"For the servers equipped with Hypervisor-based virtual switches, some may
   support the standardized NVO3 encapsulation, some may not support any
encapsulation, and some may support documented (e.g. VxLAN [RFC7348], NVGRE
[RFC7637], etc.) or proprietary encapsulations."

Nits:

i) Sec 2: "It also means that the nodes in the infrastructure network
(except
   tunnel end point nodes) carry encapsulated NVO3 traffic but not
   aware of the existence of NVO3 networks."
   Should be "...but are not aware..."

Thanks,
Alia

---

From: Lucy yong <[email-masked]>
Date: Wed, 21 Dec 2016 22:20:41 +0000

Hi Alia,

Please see inline below.

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 2:32 PM
To: [email-masked]; [email-masked]
Subject: AD review of draft-ietf-nvo3-use-case-14

[resend with subject]

As is customary, I have done my AD review of draft-ietf-nvo3-use-case-14.  First, I would like to thank the authors - Lucy, Linda, Mehmet, Aldrin, & Vishwas - for their work on this document.   It has noticeably improved since the last time I reviewed it.
[Lucy] Thank you for the comments.

As part of my review, I do have a few minor comments below that I would like to see addressed.   I am going to assume that the authors will be responsive and request an IETF Last Call now - and schedule this document for the Jan 19 IESG telechat.   I have also requested a Routing Directorate review.
[Lucy] See my response on your comments below. I am a bit confuse on the second sentence above, do you mean that we as authors need to request an IETF Last Call now? if yes, how to do that?
Minor:

1) Sec 1: "Independent address spaces in individual NVO3 networks such as MAC, IP, TCP/UDP etc."  I have no idea what you mean by TCP/UDP being an independent address space.  Please either clarify or remove it.
[Lucy] Good catch. We should remove TCP/UDP from the list. (don’t know why it was there. ☹)

2) Sec 2:"It also means that the nodes in the infrastructure network (except
   tunnel end point nodes) carry encapsulated NVO3 traffic but not
   aware of the existence of NVO3 networks."
   From discussions on the NVO3 encapsulation, there seem to be some perspectives that nodes in the infrastructure network may have reasons (OAM, etc) to be aware of the NVO3 networks.  Can you tone this down to the following?

 "It also means that the nodes in the infrastructure network (except tunnel end point nodes) carry encapsulated NVO3 traffic but are not responsible for decapsulating or encapsulating NVO3 traffic."
[Lucy] Accept you comment, but the first part and second part in your sentence seem redundant. How about: It also means that the nodes in the infratructure network treats NVO3 packets as of an IP packet from a host. Or just remove orignal sentence?

3) Sec 4.1:"For the servers equipped with Hypervisor-based virtual switches, some may
   support VxLAN [RFC7348] encapsulation, some may support NVGRE
   encapsulation [RFC7637], and some may not support any encapsulation."

This should at least mention the existence of the NVO3 encapsulation and indicate that VxLAN and NVGRE are not standards.  For instance:

"For the servers equipped with Hypervisor-based virtual switches, some may
   support the standardized NVO3 encapsulation, some may not support any encapsulation, and some may support documented (e.g. VxLAN [RFC7348], NVGRE [RFC7637], etc.) or proprietary encapsulations."
[Lucy] Good suggestion. I will replace it with your words.

Nits:

i) Sec 2: "It also means that the nodes in the infrastructure network (except
   tunnel end point nodes) carry encapsulated NVO3 traffic but not
   aware of the existence of NVO3 networks."
   Should be "...but are not aware..."
[Lucy] Thx. the sentence will be replaced according to your comments.

Thanks,
Lucy

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Dec 2016 17:26:21 -0500

Hi Lucy,

On Wed, Dec 21, 2016 at 5:20 PM, Lucy yong <[email-masked]> wrote:

> *Hi Alia,*
>
>
>
> *Please see inline below.*
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, December 21, 2016 2:32 PM
> *To:* [email-masked]; [email-masked]
> *Subject:* AD review of draft-ietf-nvo3-use-case-14
>
>
>
> [resend with subject]
>
>
> *[Lucy] Thank you for the comments.*
>
>
>
> *[Lucy] *See my response on your comments below. I am a bit confuse on
> the second sentence above, do you mean that we as authors need to request
> an IETF Last Call now? if yes, how to do that?
>

[Alia] I have already requested IETF Last Call.

> *[Lucy] Good catch. We should remove TCP/UDP from the list. (don’t know
> why it was there. **L**)*
>
>
>
>  "It also means that the nodes in the infrastructure network (except
> tunnel end point nodes) carry encapsulated NVO3 traffic but are not
> responsible for decapsulating or encapsulating NVO3 traffic."
>
> *[Lucy] Accept you comment, but the first part and second part in your
> sentence seem redundant. How about: It also means that the nodes in the
> infratructure network treats NVO3 packets as of an IP packet from a host.
> Or just remove orignal sentence?*
>

[Alia] I see your point. Perhaps removing the sentence is best.  I haven't
seen enough discussion on the mailing list to propose a more detailed
suggestion & I don't think the sentence adds noticeably to the document's
meaning.

Regards,
Alia

> *[Lucy] Good suggestion. I will replace it with your words.*
>
>
>
> Nits:
>
> *[Lucy] Thx. the sentence will be replaced according to your comments.*
>
>
>
> *Thanks,*
>
> *Lucy*
>
>
>
> Thanks,
> Alia
>
>
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 21 Dec 2016 22:35:00 +0000

Hi Alia,

Got them. Thx.

One more thought on the following:

For the servers equipped with Hypervisor-based virtual switches, some may
   support the standardized NVO3 encapsulation, some may not support any encapsulation, and some may support documented (e.g. VxLAN [RFC7348], NVGRE [RFC7637], etc.) or proprietary encapsulations.

Since we don’t have a standardized NVO3 encapsulation now, is it proper to state it? Maybe just put a note to state that VXLAN and NVGRE were published as informational document; neither is standardized NVO3 encapsulation protocol at the original text.

Regards,
Lucy

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 4:26 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-nvo3-use-case-14

Hi Lucy,

On Wed, Dec 21, 2016 at 5:20 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Please see inline below.

From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, December 21, 2016 2:32 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: AD review of draft-ietf-nvo3-use-case-14

[resend with subject]

Minor:

[Alia] I see your point. Perhaps removing the sentence is best.  I haven't seen enough discussion on the mailing list to propose a more detailed suggestion & I don't think the sentence adds noticeably to the document's meaning.

Regards,
Alia

Nits:

Thanks,
Lucy

Thanks,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Dec 2016 17:39:12 -0500

HI Lucy,

On Wed, Dec 21, 2016 at 5:35 PM, Lucy yong <[email-masked]> wrote:

> [RFC7637], etc.) or proprietary encapsulations.
>
>
>
> Since we don’t have a standardized NVO3 encapsulation now, is it proper to
> state it? Maybe just put a note to state that VXLAN and NVGRE were
> published as informational document; neither is standardized NVO3
> encapsulation protocol at the original text.
>

Yes, I think so,  since this is use-cases and the WG is heading in that
direction.  You could have it be "a standardized NVO3 encapsulation", if
you prefer.

> *Sent:* Wednesday, December 21, 2016 4:26 PM
> *To:* Lucy yong
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: AD review of draft-ietf-nvo3-use-case-14
>
>
>
> Hi Lucy,
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Dec 2016 15:25:48 -0800

On 12/21/2016 2:20 PM, Lucy yong wrote:
> as MAC, IP, TCP/UDP etc."  I have no idea what you mean by TCP/UDP
> being an independent address space.  Please either clarify or remove it.
>
> */[Lucy] Good catch. We should remove TCP/UDP from the list. (don’t
> know why it was there. /**/L/**//*
>
Was this intended to refer to the port number space?

Joe

---

From: Lucy yong <[email-masked]>
Date: Wed, 21 Dec 2016 23:38:10 +0000

Hi Joe,

That was an error. It has been corrected in the new version.

Regards,
Lucy

From: Joe Touch [mailto:[email-masked]]
Sent: Wednesday, December 21, 2016 5:26 PM
To: Lucy yong; Alia Atlas; [email-masked]; [email-masked]
Subject: Re: [nvo3] AD review of draft-ietf-nvo3-use-case-14

On 12/21/2016 2:20 PM, Lucy yong wrote:
1) Sec 1: "Independent address spaces in individual NVO3 networks such as MAC, IP, TCP/UDP etc."  I have no idea what you mean by TCP/UDP being an independent address space.  Please either clarify or remove it.
[Lucy] Good catch. We should remove TCP/UDP from the list. (don't know why it was there. :(
Was this intended to refer to the port number space?

Joe