Subject: Re: [nvo3] Poll for WG Adoption of draft-kreeger-nvo3-overlay-cp-04

From: Lizhong Jin <[email-masked]>
Date: Mon, 1 Jul 2013 23:22:10 +0800

Hi all,
Yes, support. There is two comments as below.

Fast acquisition of needed state. For example, when a Tenant System emits a
packet destined to an inner address that the NVE does not have a mapping
for, the NVE should be able to acquire the needed mapping quickly.
[Lizhong] a mechanism should be provided to let NVE know whether the
required mapping is existed on NVA or not. If the required mapping is not
existed, special action could be applied (e.g, drop packet) to avoid
accessing NVA.

One more  comment for section 3.1 Inner to Outer Address Mapping. The
destination inner address here, I think refer to destination IP/MAC
address. But from my view, this is a bit narrow concept. A flow to outer
address mapping would be a more general concept. The flow could be defined
with any fields in the packet header.

Regards
Lizhong

>
>
> ---------- Forwarded message ----------
> From: Benson Schliesser <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc:
> Date: Thu, 27 Jun 2013 21:25:48 -0400
> Subject: [nvo3] Poll for WG Adoption of draft-kreeger-nvo3-overlay-cp-04
> This email begins a two week poll to help the chairs judge if there is
> consensus to adopt draft-kreeger-nvo3-overlay-cp-**04 as an NVO3 working
> group draft.
>
> Please respond to this email on the list with 'support' or 'do not
> support'.
>
> Please also send any comments on the draft to the NVO3 list.
>
> We are also polling for knowledge of any IPR that applies to this draft,
> to ensure that IPR has been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
> If you are listed as a document author or contributor, please respond to
> this email whether or not you are aware of any relevant IPR. The draft will
> not be adopted until a response has been received from each author and
> contributor.
>
> If you are on the NVO3 WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any
> IPR that has not yet been disclosed in conformance with IETF rules.
>
> This poll closes on 11 July 2013.
>
> Cheers,
> -Benson & Matthew
>
>
>
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 1 Jul 2013 19:19:12 -0400

Hi Lizhong

> One more comment for section 3.1 Inner to Outer Address Mapping. The destination inner
> address here, I think refer to destination IP/MAC address. But from my view, this is
> a bit narrow concept. A flow to outer address mapping would be a more general concept.
> The flow could be defined with any fields in the packet header.

I think you're right about that, although the language to express it will need to be written with care.

If a remote NVE has multiple addresses, this additional classification based on non-address fields in the packet may make sense to separate traffic by more than destination address, e.g., put different sorts of traffic into separate tunnels to the same NVE where the tunnels use different network infrastructure or otherwise get treated differently by the underlay.  OTOH, it should not be the case that the location for ultimate delivery of the encapsulated traffic depends on non-address fields in the packet header.

The simple case for the latter is that for a given NVE, the same destination address maps to the same remote NVE (although that remote NVE might vary over time, e.g., due to failover).  I'm not at all sure about tackling association of a TS w/multiple NVEs for the same virtual network in a fashion that allows encapsulate traffic for the same overlay destination to be sent via more than one remote NVE.

Thanks,
--David

From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Monday, July 01, 2013 11:22 AM
To: [email-masked]; Benson Schliesser
Subject: Re: [nvo3] Poll for WG Adoption of draft-kreeger-nvo3-overlay-cp-04

Hi all,

Fast acquisition of needed state. For example, when a Tenant System emits a packet destined to an inner address that the NVE does not have a mapping for, the NVE should be able to acquire the needed mapping quickly.
[Lizhong] a mechanism should be provided to let NVE know whether the required mapping is existed on NVA or not. If the required mapping is not existed, special action could be applied (e.g, drop packet) to avoid accessing NVA.

One more  comment for section 3.1 Inner to Outer Address Mapping. The destination inner address here, I think refer to destination IP/MAC address. But from my view, this is a bit narrow concept. A flow to outer address mapping would be a more general concept. The flow could be defined with any fields in the packet header.

Regards
Lizhong

---------- Forwarded message ----------
From: Benson Schliesser <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Thu, 27 Jun 2013 21:25:48 -0400
Subject: [nvo3] Poll for WG Adoption of draft-kreeger-nvo3-overlay-cp-04
This email begins a two week poll to help the chairs judge if there is consensus to adopt draft-kreeger-nvo3-overlay-cp-04 as an NVO3 working group draft.

Please respond to this email on the list with 'support' or 'do not support'.

We are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor, please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor.

If you are on the NVO3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Cheers,
-Benson & Matthew

---

From: Lizhong Jin <[email-masked]>
Date: Tue, 2 Jul 2013 22:28:36 +0800

> destination inner****
> > address here, I think refer to destination IP/MAC address. But from my
> view, this is****
>
> > a bit narrow concept. A flow to outer address mapping would be a more
> general concept.****
>
> > The flow could be defined with any fields in the packet header.****
>
> ** **
>
> I think you’re right about that, although the language to express it will
> need to be written with care.
>
[Lizhong] yes, in practice, the fields like DPORT, SPORT,  flow label,
protocol number and etc could be used to do classification.

> ****
>
> ** **
>
> If a remote NVE has multiple addresses, this additional classification
> based on non-address fields in the packet may make sense to separate
> traffic by more than destination address, e.g., put different sorts of
> traffic into separate tunnels to the same NVE where the tunnels use
> different network infrastructure or otherwise get treated differently by
> the underlay.  OTOH, it should not be the case that the location for
> ultimate delivery of the encapsulated traffic depends on non-address fields
> in the packet header.****
>
> ** **
>
> The simple case for the latter is that for a given NVE, the same
> destination address maps to the same remote NVE (although that remote NVE
> might vary over time, e.g., due to failover).  I’m not at all sure about
> tackling association of a TS w/multiple NVEs for the same virtual network
> in a fashion that allows encapsulate traffic for the same overlay
> destination to be sent via more than one remote NVE.
>
[Lizhong] in the case of TS multihoming to two NVEs, if loadbalancing and
active-active is required (similar with the active-active in EVPN), and if
you want to do controlled loadbalancing, then different flow (with same
dest address) could be classified to different NVE.

> ****
>
> ** **
>
> Thanks,
> --David****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Lizhong Jin
> *Sent:* Monday, July 01, 2013 11:22 AM
> *To:* [email-masked]; Benson Schliesser
> *Subject:* Re: [nvo3] Poll for WG Adoption of
> draft-kreeger-nvo3-overlay-cp-04****
>
> ** **
>
> Hi all,****
>
> Yes, support. There is two comments as below.****
>
> ** **
>
> Fast acquisition of needed state. For example, when a Tenant System emits
> a packet destined to an inner address that the NVE does not have a mapping
> for, the NVE should be able to acquire the needed mapping quickly.****
>
> accessing NVA.****
> ** **
> with any fields in the packet header.****
>
> ** **
>
> Regards****
>
> Lizhong****
>
> ** **
>
>  ****
>
>
>
> consensus to adopt draft-kreeger-nvo3-overlay-cp-04 as an NVO3 working
> group draft.
>
> ****