On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <= lucy.yong@huawei.com> wrote:

Hi Vishwas,

=A0

I do not disagree with what you= said. A lot of applications do need a centralized gateway, especially a VN= interconnecting with WAN and Internet. The nvo3-nve draft gives the recomm= endations on the choice between a gateway and distributed gateway. VN withi= n DC can benefit a lot from a distributed gateway. Some vender already impl= ement these.

=A0

Lucy

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar=
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt

=A0

Hi folks,

=A0

In my view the distributed Gateway cannot do a lot o= f the centralized functions required.

=A0

We need a single place to terminate/ start IPsec con= nections - the most common way to connect to a cloud. A lot of the control = plane to talk to the external world also needs to be centralized.=

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@hua= wei.com> wrote:

Support WG adoption if the following comments can be= addressed:

=A0

Issues with the current writing of Distributed Gatew= ay (Section 5.4):

As described in Section 5.3, a Gateway does many thi= ngs. However, I don=92t think that a NVE, if taking on the responsibility o= f a distributed Gateway, will do all the things that a conventional Gateway= does (or the list of items mentioned in the Section 5.3).=A0

=A0

First, it might be too much to ask a NVE based gatew= ay (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 Interface with external VPN domain (i.e. ou= t of Virtual Networks),

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE=A0 (it is debatable if a NVE based distributed= Gateway should take this responsibility)

The real functions perf= ormed by NVE, if designated as =93distributed gateway=94, is more like <= u>Inter-VN relay (instead of full blown Gateway function).

=A0

Second, when host =93a=94 in VN-1 sends traffic to = =93b=94 in VN-2, the data packet=92s Ethernet header has =93MAC-DA =3D Gate= way-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1=94.=A0 Most implementation= s (Microsoft Window 8 and VM NSX) allocate a =93fake MAC=94 for all the NVE= based distributed gateways to share, so that host =93a=94 can use the same= Gateway-MAC when moved to another NVE. This again is different from the co= nventional gateways.

=A0

Third, the issue of conventional gateway (i.e. a->= ;b traffic to be routed at gateway even if =93a=94 & =93b=94 are attach= ed to the same NVE) is traffic =93hairpinning=94, instead of triangular rou= ting.

=A0

Therefore, I suggest rewriting Section 5.4 as below:=

=A0

5.4 Distributed Gateway (Re-write)<= /u>

The relaying of traffic from one VN to another, espe= cially when Source and Destination are attached to the same NVE, deserves s= pecial consideration. With conventional Gateways, the traffic between TSes = on different VNs has to be traversed to the gateway, even if the Source and= Destination are attached to the save NVE, which causes traffic hairpinning= and wasted bandwidth.

=A0

As an optimization, it is desirable for individual N= VEs to take over the inter-VN relay responsibilities that are traditionally= done by conventional gateways to reduce or eliminate hairpinning issue. In= order for NVEs to perform inter-VN relay, the NVEs must have access to the= policy information needed to determine whether inter-VN communication is a= llowed. Those inter-VN communication policies are most likely to come from = NVA.

=A0

However, it is not practical for NVEs to take over a= ll functions of conventional gateways.=A0

In particular, it might be too much to ask a NVE bas= ed gateway (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE.=A0=A0

The NVEs that are capable of performing inter-VN rep= laying are called =93Distributed Gateway=94 in this document. (Note: = Inter-VN relaying capable NVE is a more accurate term). <= /u>

=A0

The NVO3 architecture should support distributed gat= eways, at least allowing some NVEs, if not all, supporting the inter-VN rel= aying function, especially when both source and destination are attached to= the same NVE.=A0 Such support requires the NVO3 control protocols include = mechanisms for the maintenance and distribution of the inter-VN policy info= rmation to the NVEs that are capable of performing inter-VN communications.=

=A0

----------------------------------------

Thanks for considering my suggested text. =

=A0

Linda Dunbar

=A0

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Bocci, Matthew (Matthew) =

Sent: Wednesday, November 13, 2013 = 7:58 AM
To: nv= o3@ietf.org

Subject: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt

=A0

This email begins a two week poll to help the chairs judge i= f there is consensus =A0to adopt=A0draft-narten-nvo3-arch-01.txt as an NVO3= working group draft.

=A0

Please respond to this email on the list with 'support&#= 39; or 'do not support'.

=A0

Please also send any comments on the draft to the NVO3 list.=

=A0

Please consider whether this draft takes the right basic app= roach, and is a good basis for the work going forward (and potential future= rechartering). It does not have to be perfect at this stage.=

=A0

Coincidentally, we are also polling for knowledge of any IPR= that applies to this draft, to ensure that IPR has been disclosed in compl= iance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more deta= ils).

=A0

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. Th= e draft will not be adopted until a response has been received from each au= thor and contributor.

=A0

If you are on the NVO3 WG email list but are not listed as a= n author or contributor, then please explicitly respond only if you are awa= re of any IPR that has not yet been disclosed in conformance with IETF rule= s.

=A0

This poll closes on Friday 29th November 2013.=

=A0

Regards

=A0

Matthew and Benson

=A0

___________________= ____________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailma= n/listinfo/nvo3

=A0

--047d7bdc0c721dc9bb04eb2b9a7a-- From vishwas.ietf@gmail.com Thu Nov 14 15:41:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACCA21E809F for ; Thu, 14 Nov 2013 15:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B7Qok0PO3+w for ; Thu, 14 Nov 2013 15:41:55 -0800 (PST) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E70F911E80E9 for ; Thu, 14 Nov 2013 15:41:54 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id ii20so137583qab.4 for ; Thu, 14 Nov 2013 15:41:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gRL+K3+rY+MnxZR5Ta18UEaITFkPa7ue0inVNkstE4E=; b=GV/oodNFN/SjNWdo4NbNGYduCjWAoOBUW9h9A/RamGl+fmfn8FOGd4HNcKgu1jh1XU N2tlDyNMfkb1b99dj/ZSuLD9HeChi0G9r4UQ9SSAvBJJqD17CCuiSWWexnfu1KdtzjVP O5bchubN/RuxA2E2vgM8QFsg2uLgibbD3dOqS6QTRWINvUQtiZu6v/iUAr452pwQFqDF nFAch8DHQdF0pahDHdyDv6UwKNgDPkWdovM9xLep3d5u7ceenSu+squiDKwAJ2Wo+TKd vo5rhMwntkNSU7CR5N3Aw9ESZm/kupCsHdClJjx2XHOOBrE1z1YkCN9rxavPPmK3p/eA h4pA== MIME-Version: 1.0 X-Received: by 10.49.27.226 with SMTP id w2mr6361981qeg.32.1384472514532; Thu, 14 Nov 2013 15:41:54 -0800 (PST) Received: by 10.140.23.85 with HTTP; Thu, 14 Nov 2013 15:41:54 -0800 (PST) In-Reply-To: References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> Date: Thu, 14 Nov 2013 15:41:54 -0800 Message-ID: From: Vishwas Manral To: Lucy yong Content-Type: multipart/alternative; boundary=047d7bdc0c726e566a04eb2ba0e3 Cc: "Bocci, Matthew $Matthew$" , "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:41:56 -0000 --047d7bdc0c726e566a04eb2ba0e3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Infact even between tiers of an Application you need firewall etc. So direct access is allowed to the Web tier but not to the mid tier etc etc. -Vishwas On Thu, Nov 14, 2013 at 3:40 PM, Vishwas Manral wro= te: > Hi Lucy, > > I see the VPC as a branch of a bigger Infrastructure (in many cases), and > the gateway that connects the same as an edge device. > > We need to connect this VPC securely - and IPsec as the technology when > connecting over the internet. I dont know if you can distribute IPsec > functionality. I know you need tecnologies like firewalls etc too, which = I > know can be centrally managed yet be enforced in a distributed manner (no= t > the general way to do it however). Same with the control plane that > connects to the peers in the Enterprise (we need a single control plane). > > I guess I am missing the point. > > Thanks, > Vishwas > > On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong wrote: > >> Hi Vishwas, >> >> >> >> I do not disagree with what you said. A lot of applications do need a >> centralized gateway, especially a VN interconnecting with WAN and Intern= et. >> The nvo3-nve draft gives the recommendations on the choice between a >> gateway and distributed gateway. VN within DC can benefit a lot from a >> distributed gateway. Some vender already implement these. >> >> >> >> Lucy >> >> >> >> *From:* nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] *On Behalf >> Of *Vishwas Manral >> *Sent:* Thursday, November 14, 2013 5:07 PM >> *To:* Linda Dunbar >> *Cc:* Bocci, Matthew (Matthew); nvo3@ietf.org >> *Subject:* Re: [nvo3] Poll for WG adoption and IPR check for >> draft-narten-nvo3-arch-01.txt >> >> >> >> Hi folks, >> >> >> >> In my view the distributed Gateway cannot do a lot of the centralized >> functions required. >> >> >> >> We need a single place to terminate/ start IPsec connections - the most >> common way to connect to a cloud. A lot of the control plane to talk to = the >> external world also needs to be centralized. >> >> >> >> Thanks, >> >> Vishwas >> >> On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar >> wrote: >> >> Support WG adoption if the following comments can be addressed: >> >> >> >> Issues with the current writing of Distributed Gateway (Section 5.4): >> >> As described in Section 5.3, a Gateway does many things. However, I don= =92t >> think that a NVE, if taking on the responsibility of a distributed Gatew= ay, >> will do all the things that a conventional Gateway does (or the list of >> items mentioned in the Section 5.3). >> >> >> >> First, it might be too much to ask a NVE based gateway (especially >> Hypervisor based NVE) to >> >> =B7 relay traffic off the virtual networks, i.e. perform gateway >> function to reach destinations outside the local VNs, >> >> =B7 Interface with external VPN domain (i.e. out of Virtual >> Networks), >> >> =B7 perform NAT on the source virtual addresses, or >> >> =B7 relay traffic to a VN that doesn=92t have any hosts attached = to >> the NVE (it is debatable if a NVE based distributed Gateway should take >> this responsibility) >> >> The real functions performed by NVE, if designated as =93distributed >> gateway=94, is more like *Inter-VN relay *(instead of full blown Gateway >> function). >> >> >> >> Second, when host =93a=94 in VN-1 sends traffic to =93b=94 in VN-2, the = data >> packet=92s Ethernet header has =93MAC-DA =3D Gateway-MAC & MAC-SA=3D a-M= AC & VLAN=3D >> VN-1=94. Most implementations (Microsoft Window 8 and VM NSX) allocate = a >> =93fake MAC=94 for all the NVE based distributed gateways to share, so t= hat >> host =93a=94 can use the same Gateway-MAC when moved to another NVE. Thi= s again >> is different from the conventional gateways. >> >> >> >> Third, the issue of conventional gateway (i.e. a->b traffic to be routed >> at gateway even if =93a=94 & =93b=94 are attached to the same NVE) is tr= affic >> =93hairpinning=94, instead of triangular routing. >> >> >> >> Therefore, I suggest rewriting Section 5.4 as below: >> >> >> >> *5.4 Distributed Gateway (Re-write)* >> >> The relaying of traffic from one VN to another, especially when Source >> and Destination are attached to the same NVE, deserves special >> consideration. With conventional Gateways, the traffic between TSes on >> different VNs has to be traversed to the gateway, even if the Source and >> Destination are attached to the save NVE, which causes traffic hairpinni= ng >> and wasted bandwidth. >> >> >> >> As an optimization, it is desirable for individual NVEs to take over the >> inter-VN relay responsibilities that are traditionally done by conventio= nal >> gateways to reduce or eliminate hairpinning issue. In order for NVEs to >> perform inter-VN relay, the NVEs must have access to the policy informat= ion >> needed to determine whether inter-VN communication is allowed. Those >> inter-VN communication policies are most likely to come from NVA. >> >> >> >> However, it is not practical for NVEs to take over all functions of >> conventional gateways. >> >> In particular, it might be too much to ask a NVE based gateway >> (especially Hypervisor based NVE) to >> >> =B7 relay traffic off the virtual networks, i.e. perform gateway >> function to reach destinations outside the local VNs, >> >> =B7 perform NAT on the source virtual addresses, or >> >> =B7 relay traffic to a VN that doesn=92t have any hosts attached = to >> the NVE. >> >> The NVEs that are capable of performing inter-VN replaying are called >> =93Distributed Gateway=94 in this document. (Note: *Inter-VN relaying >> capable NVE* is a more accurate term). >> >> >> >> The NVO3 architecture should support distributed gateways, at least >> allowing some NVEs, if not all, supporting the inter-VN relaying functio= n, >> especially when both source and destination are attached to the same NVE= . >> Such support requires the NVO3 control protocols include mechanisms for = the >> maintenance and distribution of the inter-VN policy information to the N= VEs >> that are capable of performing inter-VN communications. >> >> >> >> ---------------------------------------- >> >> Thanks for considering my suggested text. >> >> >> >> Linda Dunbar >> >> >> >> >> >> *From:* nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] *On Behalf >> Of *Bocci, Matthew (Matthew) >> >> >> *Sent:* Wednesday, November 13, 2013 7:58 AM >> *To:* nvo3@ietf.org >> >> *Subject:* [nvo3] Poll for WG adoption and IPR check for >> draft-narten-nvo3-arch-01.txt >> >> >> >> This email begins a two week poll to help the chairs judge if there is >> consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working gro= up >> 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. >> >> >> >> Please consider whether this draft takes the right basic approach, and i= s >> a good basis for the work going forward (and potential future >> rechartering). It does not have to be perfect at this stage. >> >> >> >> Coincidentally, we are also polling for knowledge of any IPR that applie= s >> 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 w= ill >> 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 Friday 29th November 2013. >> >> >> >> Regards >> >> >> >> Matthew and Benson >> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> > > --047d7bdc0c726e566a04eb2ba0e3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Infact even between tiers of an Application you need firewall etc. So = direct access is allowed to the Web tier but not to the mid tier etc etc.
=A0

-Vishwas

On Thu, Nov 14, 2013 at 3:40 PM, Vishwas Manral = <vishwas.ietf@gmail.com> wrote:

Hi Lucy,

=A0

I see the VPC as a branch of a bigger Infrastructure (in many cases), = and the gateway that connects the same as an edge device.

=A0

We need to connect this VPC securely - and IPsec as the technology whe= n connecting over the internet. I dont know if you can distribute IPsec fun= ctionality. I know you need tecnologies like firewalls etc too, which I kno= w can be centrally managed yet be enforced in a distributed manner (not the= general way to do it however). Same with the control plane that connects t= o the peers in the Enterprise (we need a single control plane).

=A0

I guess I am missing the point.

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <= lucy.yong@huawei.com> wrote:

Hi Vishwas,

=A0

I do not disagree with what you= said. A lot of applications do need a centralized gateway, especially a VN= interconnecting with WAN and Internet. The nvo3-nve draft gives the recomm= endations on the choice between a gateway and distributed gateway. VN withi= n DC can benefit a lot from a distributed gateway. Some vender already impl= ement these.

=A0

Lucy

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar=
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt

=A0

Hi folks,

=A0

In my view the distributed Gateway cannot do a lot o= f the centralized functions required.

=A0

We need a single place to terminate/ start IPsec con= nections - the most common way to connect to a cloud. A lot of the control = plane to talk to the external world also needs to be centralized.=

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@hua= wei.com> wrote:

Support WG adoption if the following comments can be= addressed:

=A0

Issues with the current writing of Distributed Gatew= ay (Section 5.4):

As described in Section 5.3, a Gateway does many thi= ngs. However, I don=92t think that a NVE, if taking on the responsibility o= f a distributed Gateway, will do all the things that a conventional Gateway= does (or the list of items mentioned in the Section 5.3).=A0

=A0

First, it might be too much to ask a NVE based gatew= ay (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 Interface with external VPN domain (i.e. ou= t of Virtual Networks),

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE=A0 (it is debatable if a NVE based distributed= Gateway should take this responsibility)

The real functions perf= ormed by NVE, if designated as =93distributed gateway=94, is more like <= u>Inter-VN relay (instead of full blown Gateway function).

=A0

Second, when host =93a=94 in VN-1 sends traffic to = =93b=94 in VN-2, the data packet=92s Ethernet header has =93MAC-DA =3D Gate= way-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1=94.=A0 Most implementation= s (Microsoft Window 8 and VM NSX) allocate a =93fake MAC=94 for all the NVE= based distributed gateways to share, so that host =93a=94 can use the same= Gateway-MAC when moved to another NVE. This again is different from the co= nventional gateways.

=A0

Third, the issue of conventional gateway (i.e. a->= ;b traffic to be routed at gateway even if =93a=94 & =93b=94 are attach= ed to the same NVE) is traffic =93hairpinning=94, instead of triangular rou= ting.

=A0

Therefore, I suggest rewriting Section 5.4 as below:=

=A0

5.4 Distributed Gateway (Re-write)<= /u>

The relaying of traffic from one VN to another, espe= cially when Source and Destination are attached to the same NVE, deserves s= pecial consideration. With conventional Gateways, the traffic between TSes = on different VNs has to be traversed to the gateway, even if the Source and= Destination are attached to the save NVE, which causes traffic hairpinning= and wasted bandwidth.

=A0

As an optimization, it is desirable for individual N= VEs to take over the inter-VN relay responsibilities that are traditionally= done by conventional gateways to reduce or eliminate hairpinning issue. In= order for NVEs to perform inter-VN relay, the NVEs must have access to the= policy information needed to determine whether inter-VN communication is a= llowed. Those inter-VN communication policies are most likely to come from = NVA.

=A0

However, it is not practical for NVEs to take over a= ll functions of conventional gateways.=A0

In particular, it might be too much to ask a NVE bas= ed gateway (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE.=A0=A0

The NVEs that are capable of performing inter-VN rep= laying are called =93Distributed Gateway=94 in this document. (Note: = Inter-VN relaying capable NVE is a more accurate term). <= /u>

=A0

The NVO3 architecture should support distributed gat= eways, at least allowing some NVEs, if not all, supporting the inter-VN rel= aying function, especially when both source and destination are attached to= the same NVE.=A0 Such support requires the NVO3 control protocols include = mechanisms for the maintenance and distribution of the inter-VN policy info= rmation to the NVEs that are capable of performing inter-VN communications.=

=A0

----------------------------------------

Thanks for considering my suggested text. =

=A0

Linda Dunbar

=A0

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Bocci, Matthew (Matthew) =

Sent: Wednesday, November 13, 2013 = 7:58 AM
To: nv= o3@ietf.org

Subject: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt

=A0

This email begins a two week poll to help the chairs judge i= f there is consensus =A0to adopt=A0draft-narten-nvo3-arch-01.txt as an NVO3= working group draft.

=A0

Please respond to this email on the list with 'support&#= 39; or 'do not support'.

=A0

Please also send any comments on the draft to the NVO3 list.=

=A0

Please consider whether this draft takes the right basic app= roach, and is a good basis for the work going forward (and potential future= rechartering). It does not have to be perfect at this stage.=

=A0

Coincidentally, we are also polling for knowledge of any IPR= that applies to this draft, to ensure that IPR has been disclosed in compl= iance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more deta= ils).

=A0

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. Th= e draft will not be adopted until a response has been received from each au= thor and contributor.

=A0

If you are on the NVO3 WG email list but are not listed as a= n author or contributor, then please explicitly respond only if you are awa= re of any IPR that has not yet been disclosed in conformance with IETF rule= s.

=A0

This poll closes on Friday 29th November 2013.=

=A0

Regards

=A0

Matthew and Benson

=A0

___________________= ____________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailma= n/listinfo/nvo3

=A0

--047d7bdc0c726e566a04eb2ba0e3-- From lucy.yong@huawei.com Thu Nov 14 15:45:35 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CDE21E809F for ; Thu, 14 Nov 2013 15:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.06 X-Spam-Level: X-Spam-Status: No, score=-6.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1ueiOoSw8eN for ; Thu, 14 Nov 2013 15:45:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6E10821E808A for ; Thu, 14 Nov 2013 15:45:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX26648; Thu, 14 Nov 2013 23:45:26 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 23:45:03 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 23:45:23 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 15:45:11 -0800 From: Lucy yong To: Vishwas Manral Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4Y5KhqWJuy2kRk2jEpU+a6sf/ZolWxkQgACNmgD//3pp8A== Date: Thu, 14 Nov 2013 23:45:10 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EDED8@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.30] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EDED8dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Bocci, Matthew $Matthew$" , "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:45:35 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EDED8dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vis= hwas Manral Sent: Thursday, November 14, 2013 5:40 PM To: Lucy yong Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi Lucy, I see the VPC as a branch of a bigger Infrastructure (in many cases), and t= he gateway that connects the same as an edge device. [Lucy] VPN is the case for a VN to interconnect with external network (ent= erprise) via WAN. For such case, a gateway is more proper. The architecture= give you option to use centralized gateway or distributed gateway dependin= g the applications. There are a lot of internal VNs in DC, when they need i= nterconnect, distributed GW make sense. As Linda said, both VMare and Micro= soft already implement these. If not use case, why do you do that? Lucy We need to connect this VPC securely - and IPsec as the technology when con= necting over the internet. I dont know if you can distribute IPsec function= ality. I know you need tecnologies like firewalls etc too, which I know can= be centrally managed yet be enforced in a distributed manner (not the gene= ral way to do it however). Same with the control plane that connects to the= peers in the Enterprise (we need a single control plane). I guess I am missing the point. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong > wrote: Hi Vishwas, I do not disagree with what you said. A lot of applications do need a centr= alized gateway, especially a VN interconnecting with WAN and Internet. The = nvo3-nve draft gives the recommendations on the choice between a gateway an= d distributed gateway. VN within DC can benefit a lot from a distributed ga= teway. Some vender already implement these. Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, November 14, 2013 5:07 PM To: Linda Dunbar Cc: Bocci, Matthew (Matthew); nvo3@ietf.org Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi folks, In my view the distributed Gateway cannot do a lot of the centralized funct= ions required. We need a single place to terminate/ start IPsec connections - the most com= mon way to connect to a cloud. A lot of the control plane to talk to the ex= ternal world also needs to be centralized. Thanks, Vishwas On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar > wrote: Support WG adoption if the following comments can be addressed: Issues with the current writing of Distributed Gateway (Section 5.4): As described in Section 5.3, a Gateway does many things. However, I don't t= hink that a NVE, if taking on the responsibility of a distributed Gateway, = will do all the things that a conventional Gateway does (or the list of ite= ms mentioned in the Section 5.3). First, it might be too much to ask a NVE based gateway (especially Hypervis= or based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * Interface with external VPN domain (i.e. out of Virtual Networks), * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE (it is debatable if a NVE based distributed Gateway should take this r= esponsibility) The real functions performed by NVE, if designated as "distributed gateway"= , is more like Inter-VN relay (instead of full blown Gateway function). Second, when host "a" in VN-1 sends traffic to "b" in VN-2, the data packet= 's Ethernet header has "MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D = VN-1". Most implementations (Microsoft Window 8 and VM NSX) allocate a "fa= ke MAC" for all the NVE based distributed gateways to share, so that host "= a" can use the same Gateway-MAC when moved to another NVE. This again is di= fferent from the conventional gateways. Third, the issue of conventional gateway (i.e. a->b traffic to be routed at= gateway even if "a" & "b" are attached to the same NVE) is traffic "hairpi= nning", instead of triangular routing. Therefore, I suggest rewriting Section 5.4 as below: 5.4 Distributed Gateway (Re-write) The relaying of traffic from one VN to another, especially when Source and = Destination are attached to the same NVE, deserves special consideration. W= ith conventional Gateways, the traffic between TSes on different VNs has to= be traversed to the gateway, even if the Source and Destination are attach= ed to the save NVE, which causes traffic hairpinning and wasted bandwidth. As an optimization, it is desirable for individual NVEs to take over the in= ter-VN relay responsibilities that are traditionally done by conventional g= ateways to reduce or eliminate hairpinning issue. In order for NVEs to perf= orm inter-VN relay, the NVEs must have access to the policy information nee= ded to determine whether inter-VN communication is allowed. Those inter-VN = communication policies are most likely to come from NVA. However, it is not practical for NVEs to take over all functions of convent= ional gateways. In particular, it might be too much to ask a NVE based gateway (especially = Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE. The NVEs that are capable of performing inter-VN replaying are called "Dist= ributed Gateway" in this document. (Note: Inter-VN relaying capable NVE is = a more accurate term). The NVO3 architecture should support distributed gateways, at least allowin= g some NVEs, if not all, supporting the inter-VN relaying function, especia= lly when both source and destination are attached to the same NVE. Such su= pport requires the NVO3 control protocols include mechanisms for the mainte= nance and distribution of the inter-VN policy information to the NVEs that = are capable of performing inter-VN communications. ---------------------------------------- Thanks for considering my suggested text. Linda Dunbar From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Ma= tthew) Sent: Wednesday, November 13, 2013 7:58 AM To: nvo3@ietf.org Subject: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-ar= ch-01.txt This email begins a two week poll to help the chairs judge if there is cons= ensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draf= t. 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. Please consider whether this draft takes the right basic approach, and is a= good basis for the work going forward (and potential future rechartering).= It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. If you are on the NVO3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D452EDED8dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vishwas,

<= /p>

From: nvo3-bou= nces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:40 PM
To: Lucy yong
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi Lucy,

I see the VPC as a branch of a bigger Infrastructure= (in many cases), and the gateway that connects the same as an edge device.=

[Lucy] VPN is = ;the case for a VN to interconnect with external network (enterprise) via W= AN. For such case, a gateway is more proper. The architecture give you option to use centralized gateway or distributed gateway dependin= g the applications. There are a lot of internal VNs in DC, when they need i= nterconnect, distributed GW make sense. As Linda said, both VMare and Micro= soft already implement these. If not use case, why do you do that?

Lucy=

We need to connect this VPC securely - and IPsec as = the technology when connecting over the internet. I dont know if you can di= stribute IPsec functionality. I know you need tecnologies like firewalls et= c too, which I know can be centrally managed yet be enforced in a distributed manner (not the general way to do= it however). Same with the control plane that connects to the peers in the= Enterprise (we need a single control plane).

I guess I am missing the point.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Hi Vishwas,

I do not disagree with what you said. A= lot of applications do need a centralized gateway, especially a VN interconnecting with WAN and Internet. The nvo3-nve draft gives the r= ecommendations on the choice between a gateway and distributed gateway. VN = within DC can benefit a lot from a distributed gateway. Some vender already= implement these.

Lucy

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi folks,

In my view the distributed Gateway cannot do a lot of the centrali= zed functions required.

We need a single place to terminate/ start IPsec connections - the= most common way to connect to a cloud. A lot of the control plane to talk = to the external world also needs to be centralized.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@huawei.com>= ; wrote:

Support WG adoption if the following comments can be addressed:

Issues with the current writing of Distributed Gateway (Section 5.= 4):

As described in Section 5.3, a Gateway does many things. However, = I don’t think that a NVE, if taking on the responsibility of a distri= buted Gateway, will do all the things that a conventional Gateway does (or the list of items mentioned in the Section= 5.3).

First, it might be too much to ask a NVE based gateway (especially= Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        Interface with external VPN domain (i.e. out of Virtual Networks), <= o:p>

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE (it is debatable if a NVE based distributed Gateway should ta= ke this responsibility)

The real functions performed by NVE, if designated as “distributed ga= teway”, is more like Inter-VN relay (instead of full blown Gateway function).=

Second, when host “a” in VN-1 sends traffic to “= b” in VN-2, the data packet’s Ethernet header has “MAC-DA= =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1”. Mos= t implementations (Microsoft Window 8 and VM NSX) allocate a “fake MAC” for all the NVE bas= ed distributed gateways to share, so that host “a” can use the = same Gateway-MAC when moved to another NVE. This again is different from th= e conventional gateways.

Third, the issue of conventional gateway (i.e. a->b traffic to = be routed at gateway even if “a” & “b” are atta= ched to the same NVE) is traffic “hairpinning”, instead of tria= ngular routing.

Therefore, I suggest rewriting Section 5.4 as below:

5.4 Distributed Gateway (Re-write)

The relaying of traffic from one VN to another, especially when So= urce and Destination are attached to the same NVE, deserves special conside= ration. With conventional Gateways, the traffic between TSes on different VNs has to be traversed to the gatew= ay, even if the Source and Destination are attached to the save NVE, which = causes traffic hairpinning and wasted bandwidth.

As an optimization, it is desirable for individual NVEs to take ov= er the inter-VN relay responsibilities that are traditionally done by conve= ntional gateways to reduce or eliminate hairpinning issue. In order for NVEs to perform inter-VN relay, the NVEs m= ust have access to the policy information needed to determine whether inter= -VN communication is allowed. Those inter-VN communication policies are mos= t likely to come from NVA.

However, it is not practical for NVEs to take over all functions o= f conventional gateways.

In particular, it might be too much to ask a NVE based gateway (es= pecially Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE.

The NVEs that are capable of performing inter-VN replaying are cal= led “Distributed Gateway” in this document. (Note: Inter-VN relaying capable NVE is a more accurate term). =

The NVO3 architecture should support distributed gateways, at leas= t allowing some NVEs, if not all, supporting the inter-VN relaying function= , especially when both source and destination are attached to the same NVE. Such support requires the NVO3 control= protocols include mechanisms for the maintenance and distribution of the i= nter-VN policy information to the NVEs that are capable of performing inter= -VN communications.

----------------------------------------

Thanks for considering my suggested text.

Linda Dunbar

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)

Sent: Wednesday, November 13, 2013 7:58 AM
To: nvo3@ietf.org=

Subject: [nvo3] Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt

This email begins a two week poll to help the chairs judge if there is= consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draft.

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

Please also send any comments on the draft to the NVO3 list.

Please consider whether this draft takes the right basic approach, and= is a good basis for the work going forward (and potential future rechartering). It does not have to be perfect at this stage.=

Coincidentally, we are also polling for knowledge of any IPR that appl= ies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for mor= e details).

If you are listed as a document author or contributor please respond t= o 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 o= r contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with I= ETF rules.

This poll closes on Friday 29th November 2013.

Regards

Matthew and Benson

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D452EDED8dfweml509mbxchi_-- From lucy.yong@huawei.com Thu Nov 14 15:47:10 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B311E8138 for ; Thu, 14 Nov 2013 15:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.071 X-Spam-Level: X-Spam-Status: No, score=-6.071 tagged_above=-999 required=5 tests=[AWL=0.527, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDCiAiTC-Dq4 for ; Thu, 14 Nov 2013 15:47:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D733311E812B for ; Thu, 14 Nov 2013 15:47:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH29984; Thu, 14 Nov 2013 23:46:59 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 23:45:57 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 23:46:58 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 15:46:48 -0800 From: Lucy yong To: Vishwas Manral Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4ZMim32ljbarckSn7NgNI5u7OpolZFfA Date: Thu, 14 Nov 2013 23:46:47 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EDEE7@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.30] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EDEE7dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Bocci, Matthew $Matthew$" , "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:47:10 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EDEE7dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. NVX implement the distributed firewall too. It is also described in = nvo3-nve draft. Like to see your feedback on that draft. Lucy From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, November 14, 2013 5:42 PM To: Lucy yong Cc: Linda Dunbar; Bocci, Matthew (Matthew); nvo3@ietf.org Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Infact even between tiers of an Application you need firewall etc. So direc= t access is allowed to the Web tier but not to the mid tier etc etc. -Vishwas On Thu, Nov 14, 2013 at 3:40 PM, Vishwas Manral > wrote: Hi Lucy, I see the VPC as a branch of a bigger Infrastructure (in many cases), and t= he gateway that connects the same as an edge device. We need to connect this VPC securely - and IPsec as the technology when con= necting over the internet. I dont know if you can distribute IPsec function= ality. I know you need tecnologies like firewalls etc too, which I know can= be centrally managed yet be enforced in a distributed manner (not the gene= ral way to do it however). Same with the control plane that connects to the= peers in the Enterprise (we need a single control plane). I guess I am missing the point. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong > wrote: Hi Vishwas, I do not disagree with what you said. A lot of applications do need a centr= alized gateway, especially a VN interconnecting with WAN and Internet. The = nvo3-nve draft gives the recommendations on the choice between a gateway an= d distributed gateway. VN within DC can benefit a lot from a distributed ga= teway. Some vender already implement these. Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, November 14, 2013 5:07 PM To: Linda Dunbar Cc: Bocci, Matthew (Matthew); nvo3@ietf.org Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi folks, In my view the distributed Gateway cannot do a lot of the centralized funct= ions required. We need a single place to terminate/ start IPsec connections - the most com= mon way to connect to a cloud. A lot of the control plane to talk to the ex= ternal world also needs to be centralized. Thanks, Vishwas On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar > wrote: Support WG adoption if the following comments can be addressed: Issues with the current writing of Distributed Gateway (Section 5.4): As described in Section 5.3, a Gateway does many things. However, I don't t= hink that a NVE, if taking on the responsibility of a distributed Gateway, = will do all the things that a conventional Gateway does (or the list of ite= ms mentioned in the Section 5.3). First, it might be too much to ask a NVE based gateway (especially Hypervis= or based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * Interface with external VPN domain (i.e. out of Virtual Networks), * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE (it is debatable if a NVE based distributed Gateway should take this r= esponsibility) The real functions performed by NVE, if designated as "distributed gateway"= , is more like Inter-VN relay (instead of full blown Gateway function). Second, when host "a" in VN-1 sends traffic to "b" in VN-2, the data packet= 's Ethernet header has "MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D = VN-1". Most implementations (Microsoft Window 8 and VM NSX) allocate a "fa= ke MAC" for all the NVE based distributed gateways to share, so that host "= a" can use the same Gateway-MAC when moved to another NVE. This again is di= fferent from the conventional gateways. Third, the issue of conventional gateway (i.e. a->b traffic to be routed at= gateway even if "a" & "b" are attached to the same NVE) is traffic "hairpi= nning", instead of triangular routing. Therefore, I suggest rewriting Section 5.4 as below: 5.4 Distributed Gateway (Re-write) The relaying of traffic from one VN to another, especially when Source and = Destination are attached to the same NVE, deserves special consideration. W= ith conventional Gateways, the traffic between TSes on different VNs has to= be traversed to the gateway, even if the Source and Destination are attach= ed to the save NVE, which causes traffic hairpinning and wasted bandwidth. As an optimization, it is desirable for individual NVEs to take over the in= ter-VN relay responsibilities that are traditionally done by conventional g= ateways to reduce or eliminate hairpinning issue. In order for NVEs to perf= orm inter-VN relay, the NVEs must have access to the policy information nee= ded to determine whether inter-VN communication is allowed. Those inter-VN = communication policies are most likely to come from NVA. However, it is not practical for NVEs to take over all functions of convent= ional gateways. In particular, it might be too much to ask a NVE based gateway (especially = Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE. The NVEs that are capable of performing inter-VN replaying are called "Dist= ributed Gateway" in this document. (Note: Inter-VN relaying capable NVE is = a more accurate term). The NVO3 architecture should support distributed gateways, at least allowin= g some NVEs, if not all, supporting the inter-VN relaying function, especia= lly when both source and destination are attached to the same NVE. Such su= pport requires the NVO3 control protocols include mechanisms for the mainte= nance and distribution of the inter-VN policy information to the NVEs that = are capable of performing inter-VN communications. ---------------------------------------- Thanks for considering my suggested text. Linda Dunbar From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Ma= tthew) Sent: Wednesday, November 13, 2013 7:58 AM To: nvo3@ietf.org Subject: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-ar= ch-01.txt This email begins a two week poll to help the chairs judge if there is cons= ensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draf= t. 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. Please consider whether this draft takes the right basic approach, and is a= good basis for the work going forward (and potential future rechartering).= It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. If you are on the NVO3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D452EDEE7dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree. NVX implement the = distributed firewall too. It is also described in nvo3-nve draft. Like to s= ee your feedback on that draft.

Lucy
<= /p>

From: Vishwas = Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, November 14, 2013 5:42 PM
To: Lucy yong
Cc: Linda Dunbar; Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Infact even between tiers of an Application you need= firewall etc. So direct access is allowed to the Web tier but not to the m= id tier etc etc.

-Vishwas

On Thu, Nov 14, 2013 at 3:40 PM, Vishwas Manral <= vishwas.ietf@gm= ail.com> wrote:

Hi Lucy,

I see the VPC as a branch of a bigger Infrastructure= (in many cases), and the gateway that connects the same as an edge device.=

We need to connect this VPC securely - and IPsec as = the technology when connecting over the internet. I dont know if you can di= stribute IPsec functionality. I know you need tecnologies like firewalls et= c too, which I know can be centrally managed yet be enforced in a distributed manner (not the general way to do= it however). Same with the control plane that connects to the peers in the= Enterprise (we need a single control plane).

I guess I am missing the point.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Hi Vishwas,

I do not disagree with what you said. A= lot of applications do need a centralized gateway, especially a VN interconnecting with WAN and Internet. The nvo3-nve draft gives the r= ecommendations on the choice between a gateway and distributed gateway. VN = within DC can benefit a lot from a distributed gateway. Some vender already= implement these.

Lucy

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi folks,

In my view the distributed Gateway cannot do a lot of the centrali= zed functions required.

We need a single place to terminate/ start IPsec connections - the= most common way to connect to a cloud. A lot of the control plane to talk = to the external world also needs to be centralized.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@huawei.com>= ; wrote:

Support WG adoption if the following comments can be addressed:

Issues with the current writing of Distributed Gateway (Section 5.= 4):

As described in Section 5.3, a Gateway does many things. However, = I don’t think that a NVE, if taking on the responsibility of a distri= buted Gateway, will do all the things that a conventional Gateway does (or the list of items mentioned in the Section= 5.3).

First, it might be too much to ask a NVE based gateway (especially= Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        Interface with external VPN domain (i.e. out of Virtual Networks), <= o:p>

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE (it is debatable if a NVE based distributed Gateway should ta= ke this responsibility)

The real functions performed by NVE, if designated as “distributed ga= teway”, is more like Inter-VN relay (instead of full blown Gateway function).=

Second, when host “a” in VN-1 sends traffic to “= b” in VN-2, the data packet’s Ethernet header has “MAC-DA= =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1”. Mos= t implementations (Microsoft Window 8 and VM NSX) allocate a “fake MAC” for all the NVE bas= ed distributed gateways to share, so that host “a” can use the = same Gateway-MAC when moved to another NVE. This again is different from th= e conventional gateways.

Third, the issue of conventional gateway (i.e. a->b traffic to = be routed at gateway even if “a” & “b” are atta= ched to the same NVE) is traffic “hairpinning”, instead of tria= ngular routing.

Therefore, I suggest rewriting Section 5.4 as below:

5.4 Distributed Gateway (Re-write)

The relaying of traffic from one VN to another, especially when So= urce and Destination are attached to the same NVE, deserves special conside= ration. With conventional Gateways, the traffic between TSes on different VNs has to be traversed to the gatew= ay, even if the Source and Destination are attached to the save NVE, which = causes traffic hairpinning and wasted bandwidth.

As an optimization, it is desirable for individual NVEs to take ov= er the inter-VN relay responsibilities that are traditionally done by conve= ntional gateways to reduce or eliminate hairpinning issue. In order for NVEs to perform inter-VN relay, the NVEs m= ust have access to the policy information needed to determine whether inter= -VN communication is allowed. Those inter-VN communication policies are mos= t likely to come from NVA.

However, it is not practical for NVEs to take over all functions o= f conventional gateways.

In particular, it might be too much to ask a NVE based gateway (es= pecially Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE.

The NVEs that are capable of performing inter-VN replaying are cal= led “Distributed Gateway” in this document. (Note: Inter-VN relaying capable NVE is a more accurate term). =

The NVO3 architecture should support distributed gateways, at leas= t allowing some NVEs, if not all, supporting the inter-VN relaying function= , especially when both source and destination are attached to the same NVE. Such support requires the NVO3 control= protocols include mechanisms for the maintenance and distribution of the i= nter-VN policy information to the NVEs that are capable of performing inter= -VN communications.

----------------------------------------

Thanks for considering my suggested text.

Linda Dunbar

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)

Sent: Wednesday, November 13, 2013 7:58 AM
To: nvo3@ietf.org=

Subject: [nvo3] Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt

This email begins a two week poll to help the chairs judge if there is= consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draft.

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

Please also send any comments on the draft to the NVO3 list.

Please consider whether this draft takes the right basic approach, and= is a good basis for the work going forward (and potential future rechartering). It does not have to be perfect at this stage.=

Coincidentally, we are also polling for knowledge of any IPR that appl= ies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for mor= e details).

If you are listed as a document author or contributor please respond t= o 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 o= r contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with I= ETF rules.

This poll closes on Friday 29th November 2013.

Regards

Matthew and Benson

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D452EDEE7dfweml509mbxchi_-- From vishwas.ietf@gmail.com Thu Nov 14 15:52:31 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1512821E80C9 for ; Thu, 14 Nov 2013 15:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwOmRTdJIO5W for ; Thu, 14 Nov 2013 15:52:29 -0800 (PST) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8F21E80DC for ; Thu, 14 Nov 2013 15:52:25 -0800 (PST) Received: by mail-qe0-f41.google.com with SMTP id x7so1824073qeu.0 for ; Thu, 14 Nov 2013 15:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QP6LXNxgOVwIwKORmEarXiRD083rVbSoqj7jVp5a2oo=; b=XtJSnTmvqG8WcGW1/xVrF0o1dLQwwsd0wZ2pqbCEdQ/oOFbuoUROejgYjuGU4OhtKd rh+YeyOCGb51X7B/OXpBL0X0mZrE3Fz2sJSnIk6tO/LgRRzqWqWNuqa5tm21ikxmcnFv agVT+jxdXfn4/2mOynVrm3EYCTNdjgPxM30aCwC8jE7AodbmCWOFke1FK/Sb5z+LypXu 0kDmw/sZGMQ+h6Rc9+4XFHk/LFK7O+eICjqpjVepHm5AuvgAWUPy1itv7CTAVj8BkTSS igs5+KvrD9+Ac/4vVSSEFU15OcRfofnawysgmlC1yxM+l6ZN3aYgwoJOWQUs62BxxpuE d7uQ== MIME-Version: 1.0 X-Received: by 10.49.60.9 with SMTP id d9mr6319255qer.70.1384473145332; Thu, 14 Nov 2013 15:52:25 -0800 (PST) Received: by 10.140.23.85 with HTTP; Thu, 14 Nov 2013 15:52:25 -0800 (PST) In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452EDED8@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDED8@dfweml509-mbx.china.huawei.com> Date: Thu, 14 Nov 2013 15:52:25 -0800 Message-ID: From: Vishwas Manral To: Lucy yong Content-Type: multipart/alternative; boundary=047d7b6d9ce0075aa904eb2bc66b Cc: "Bocci, Matthew $Matthew$" , "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 23:52:31 -0000 --047d7b6d9ce0075aa904eb2bc66b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Lucy/ Linda, What I am saying is that you will need a centralized gateway even in cases you do some of the functionality that is distributed. We can talk of advantages of a disrtibuted + centralized model that are well known. Ta distributed Layer-3 gateway allows traffic within the same tier can be routed directly. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:45 PM, Lucy yong wrote: > Hi Vishwas, > > > > *From:* nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] *On Behalf > Of *Vishwas Manral > *Sent:* Thursday, November 14, 2013 5:40 PM > *To:* Lucy yong > *Cc:* Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar > > *Subject:* Re: [nvo3] Poll for WG adoption and IPR check for > draft-narten-nvo3-arch-01.txt > > > > Hi Lucy, > > > > I see the VPC as a branch of a bigger Infrastructure (in many cases), and > the gateway that connects the same as an edge device. > > *[Lucy] VPN is the case for a VN to interconnect with external network > (enterprise) via WAN. For such case, a gateway is more proper. The > architecture give you option to use centralized gateway or distributed > gateway depending the applications. There are a lot of internal VNs in DC= , > when they need interconnect, distributed GW make sense. As Linda said, bo= th > VMare and Microsoft already implement these. If not use case, why do you = do > that?* > > > > *Lucy* > > > > We need to connect this VPC securely - and IPsec as the technology when > connecting over the internet. I dont know if you can distribute IPsec > functionality. I know you need tecnologies like firewalls etc too, which = I > know can be centrally managed yet be enforced in a distributed manner (no= t > the general way to do it however). Same with the control plane that > connects to the peers in the Enterprise (we need a single control plane). > > > > I guess I am missing the point. > > > > Thanks, > > Vishwas > > On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong wrote: > > Hi Vishwas, > > > > I do not disagree with what you said. A lot of applications do need a > centralized gateway, especially a VN interconnecting with WAN and Interne= t. > The nvo3-nve draft gives the recommendations on the choice between a > gateway and distributed gateway. VN within DC can benefit a lot from a > distributed gateway. Some vender already implement these. > > > > Lucy > > > > *From:* nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] *On Behalf > Of *Vishwas Manral > *Sent:* Thursday, November 14, 2013 5:07 PM > *To:* Linda Dunbar > *Cc:* Bocci, Matthew (Matthew); nvo3@ietf.org > *Subject:* Re: [nvo3] Poll for WG adoption and IPR check for > draft-narten-nvo3-arch-01.txt > > > > Hi folks, > > > > In my view the distributed Gateway cannot do a lot of the centralized > functions required. > > > > We need a single place to terminate/ start IPsec connections - the most > common way to connect to a cloud. A lot of the control plane to talk to t= he > external world also needs to be centralized. > > > > Thanks, > > Vishwas > > On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar > wrote: > > Support WG adoption if the following comments can be addressed: > > > > Issues with the current writing of Distributed Gateway (Section 5.4): > > As described in Section 5.3, a Gateway does many things. However, I don= =92t > think that a NVE, if taking on the responsibility of a distributed Gatewa= y, > will do all the things that a conventional Gateway does (or the list of > items mentioned in the Section 5.3). > > > > First, it might be too much to ask a NVE based gateway (especially > Hypervisor based NVE) to > > =B7 relay traffic off the virtual networks, i.e. perform gateway > function to reach destinations outside the local VNs, > > =B7 Interface with external VPN domain (i.e. out of Virtual > Networks), > > =B7 perform NAT on the source virtual addresses, or > > =B7 relay traffic to a VN that doesn=92t have any hosts attached t= o > the NVE (it is debatable if a NVE based distributed Gateway should take > this responsibility) > > The real functions performed by NVE, if designated as =93distributed > gateway=94, is more like *Inter-VN relay *(instead of full blown Gateway > function). > > > > Second, when host =93a=94 in VN-1 sends traffic to =93b=94 in VN-2, the d= ata > packet=92s Ethernet header has =93MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MA= C & VLAN=3D > VN-1=94. Most implementations (Microsoft Window 8 and VM NSX) allocate a > =93fake MAC=94 for all the NVE based distributed gateways to share, so th= at > host =93a=94 can use the same Gateway-MAC when moved to another NVE. This= again > is different from the conventional gateways. > > > > Third, the issue of conventional gateway (i.e. a->b traffic to be routed > at gateway even if =93a=94 & =93b=94 are attached to the same NVE) is tra= ffic > =93hairpinning=94, instead of triangular routing. > > > > Therefore, I suggest rewriting Section 5.4 as below: > > > > *5.4 Distributed Gateway (Re-write)* > > The relaying of traffic from one VN to another, especially when Source an= d > Destination are attached to the same NVE, deserves special consideration. > With conventional Gateways, the traffic between TSes on different VNs has > to be traversed to the gateway, even if the Source and Destination are > attached to the save NVE, which causes traffic hairpinning and wasted > bandwidth. > > > > As an optimization, it is desirable for individual NVEs to take over the > inter-VN relay responsibilities that are traditionally done by convention= al > gateways to reduce or eliminate hairpinning issue. In order for NVEs to > perform inter-VN relay, the NVEs must have access to the policy informati= on > needed to determine whether inter-VN communication is allowed. Those > inter-VN communication policies are most likely to come from NVA. > > > > However, it is not practical for NVEs to take over all functions of > conventional gateways. > > In particular, it might be too much to ask a NVE based gateway (especiall= y > Hypervisor based NVE) to > > =B7 relay traffic off the virtual networks, i.e. perform gateway > function to reach destinations outside the local VNs, > > =B7 perform NAT on the source virtual addresses, or > > =B7 relay traffic to a VN that doesn=92t have any hosts attached t= o > the NVE. > > The NVEs that are capable of performing inter-VN replaying are called > =93Distributed Gateway=94 in this document. (Note: *Inter-VN relaying cap= able > NVE* is a more accurate term). > > > > The NVO3 architecture should support distributed gateways, at least > allowing some NVEs, if not all, supporting the inter-VN relaying function= , > especially when both source and destination are attached to the same NVE. > Such support requires the NVO3 control protocols include mechanisms for t= he > maintenance and distribution of the inter-VN policy information to the NV= Es > that are capable of performing inter-VN communications. > > > > ---------------------------------------- > > Thanks for considering my suggested text. > > > > Linda Dunbar > > > > > > *From:* nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] *On Behalf > Of *Bocci, Matthew (Matthew) > > > *Sent:* Wednesday, November 13, 2013 7:58 AM > *To:* nvo3@ietf.org > > *Subject:* [nvo3] Poll for WG adoption and IPR check for > draft-narten-nvo3-arch-01.txt > > > > This email begins a two week poll to help the chairs judge if there is > consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working grou= p > 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. > > > > Please consider whether this draft takes the right basic approach, and is > a good basis for the work going forward (and potential future > rechartering). It does not have to be perfect at this stage. > > > > Coincidentally, 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 wi= ll > 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 Friday 29th November 2013. > > > > Regards > > > > Matthew and Benson > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > --047d7b6d9ce0075aa904eb2bc66b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Lucy/ Linda,

=A0

What I am saying is that you will need a centralized gateway even in c= ases you do some of the functionality that is distributed.

=A0

We can talk of advantages of a disrtibuted + centralized model that ar= e well known. Ta distributed Layer-3 gateway allows traffic within the same= tier can be routed directly.

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:45 PM, Lucy yong <= lucy.yong@huawei.com> wrote:

Hi Vishwas,

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:40 PM
To: Lucy yongCc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar=20

Subject: Re: [nvo3] Poll for WG adoption and I= PR check for draft-narten-nvo3-arch-01.txt

=A0

Hi Lucy,

=A0

I see the VPC as a branch of a bigger Infrastructure= (in many cases), and the gateway that connects the same as an edge device.=

[Lucy] VPN is =A0the case= for a VN to interconnect with external network (enterprise) via WAN. For s= uch case, a gateway is more proper. The architecture give you option to use= centralized gateway or distributed gateway depending the applications. The= re are a lot of internal VNs in DC, when they need interconnect, distribute= d GW make sense. As Linda said, both VMare and Microsoft already implement = these. If not use case, why do you do that?

=A0<= /i>

Lucy

=A0

We need to connect this VPC securely - and IPsec as = the technology when connecting over the internet. I dont know if you can di= stribute IPsec functionality. I know you need tecnologies like firewalls et= c too, which I know can be centrally managed yet be enforced in a distribut= ed manner (not the general way to do it however). Same with the control pla= ne that connects to the peers in the Enterprise (we need a single control p= lane).

=A0

I guess I am missing the point.

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Hi Vishwas,

=A0

I do not disagree with what you= said. A lot of applications do need a centralized gateway, especially a VN= interconnecting with WAN and Internet. The nvo3-nve draft gives the recomm= endations on the choice between a gateway and distributed gateway. VN withi= n DC can benefit a lot from a distributed gateway. Some vender already impl= ement these.

=A0

Lucy

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar=
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt=

=A0

Hi folks,

=A0

In my view the distributed Gateway cannot do a lot o= f the centralized functions required.

=A0

We need a single place to terminate/ start IPsec con= nections - the most common way to connect to a cloud. A lot of the control = plane to talk to the external world also needs to be centralized.=

=A0

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@hua= wei.com> wrote:

Support WG adoption if the following comments can be= addressed:

=A0

Issues with the current writing of Distributed Gatew= ay (Section 5.4):

As described in Section 5.3, a Gateway does many thi= ngs. However, I don=92t think that a NVE, if taking on the responsibility o= f a distributed Gateway, will do all the things that a conventional Gateway= does (or the list of items mentioned in the Section 5.3).=A0

=A0

First, it might be too much to ask a NVE based gatew= ay (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 Interface with external VPN domain (i.e. ou= t of Virtual Networks),

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE=A0 (it is debatable if a NVE based distributed= Gateway should take this responsibility)

The real functions perf= ormed by NVE, if designated as =93distributed gateway=94, is more like <= u>Inter-VN relay (instead of full blown Gateway function).

=A0

Second, when host =93a=94 in VN-1 sends traffic to = =93b=94 in VN-2, the data packet=92s Ethernet header has =93MAC-DA =3D Gate= way-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1=94.=A0 Most implementation= s (Microsoft Window 8 and VM NSX) allocate a =93fake MAC=94 for all the NVE= based distributed gateways to share, so that host =93a=94 can use the same= Gateway-MAC when moved to another NVE. This again is different from the co= nventional gateways.

=A0

Third, the issue of conventional gateway (i.e. a->= ;b traffic to be routed at gateway even if =93a=94 & =93b=94 are attach= ed to the same NVE) is traffic =93hairpinning=94, instead of triangular rou= ting.

=A0

Therefore, I suggest rewriting Section 5.4 as below:=

=A0

5.4 Distributed Gateway (Re-write)<= /u>

The relaying of traffic from one VN to another, espe= cially when Source and Destination are attached to the same NVE, deserves s= pecial consideration. With conventional Gateways, the traffic between TSes = on different VNs has to be traversed to the gateway, even if the Source and= Destination are attached to the save NVE, which causes traffic hairpinning= and wasted bandwidth.

=A0

As an optimization, it is desirable for individual N= VEs to take over the inter-VN relay responsibilities that are traditionally= done by conventional gateways to reduce or eliminate hairpinning issue. In= order for NVEs to perform inter-VN relay, the NVEs must have access to the= policy information needed to determine whether inter-VN communication is a= llowed. Those inter-VN communication policies are most likely to come from = NVA.

=A0

However, it is not practical for NVEs to take over a= ll functions of conventional gateways.=A0

In particular, it might be too much to ask a NVE bas= ed gateway (especially Hypervisor based NVE) to

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic off the virtual networks, i.e= . perform gateway function to reach destinations outside the local VNs,=A0 =

=B7=A0=A0=A0=A0=A0=A0=A0 perform NAT on the source virtual addresses= , or

=B7=A0=A0=A0=A0=A0=A0=A0 relay traffic to a VN that doesn=92t have a= ny hosts attached to the NVE.=A0=A0

The NVEs that are capable of performing inter-VN rep= laying are called =93Distributed Gateway=94 in this document. (Note: = Inter-VN relaying capable NVE is a more accurate term). <= /u>

=A0

The NVO3 architecture should support distributed gat= eways, at least allowing some NVEs, if not all, supporting the inter-VN rel= aying function, especially when both source and destination are attached to= the same NVE.=A0 Such support requires the NVO3 control protocols include = mechanisms for the maintenance and distribution of the inter-VN policy info= rmation to the NVEs that are capable of performing inter-VN communications.=

=A0

----------------------------------------

Thanks for considering my suggested text. =

=A0

Linda Dunbar

=A0

=A0

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.= org] On Behalf Of Bocci, Matthew (Matthew) =

Sent: Wednesday, November 13, 2013 = 7:58 AM
To: nv= o3@ietf.org

Subject: [nvo3] Poll for W= G adoption and IPR check for draft-narten-nvo3-arch-01.txt

=A0

This email begins a two week poll to help the chairs judge i= f there is consensus =A0to adopt=A0draft-narten-nvo3-arch-01.txt as an NVO3= working group draft.

=A0

Please respond to this email on the list with 'support&#= 39; or 'do not support'.

=A0

Please also send any comments on the draft to the NVO3 list.=

=A0

Please consider whether this draft takes the right basic app= roach, and is a good basis for the work going forward (and potential future= rechartering). It does not have to be perfect at this stage.=

=A0

Coincidentally, we are also polling for knowledge of any IPR= that applies to this draft, to ensure that IPR has been disclosed in compl= iance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more deta= ils).

=A0

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. Th= e draft will not be adopted until a response has been received from each au= thor and contributor.

=A0

If you are on the NVO3 WG email list but are not listed as a= n author or contributor, then please explicitly respond only if you are awa= re of any IPR that has not yet been disclosed in conformance with IETF rule= s.

=A0

This poll closes on Friday 29th November 2013.=

=A0

Regards

=A0

Matthew and Benson

=A0

___________________= ____________________________
nvo3 mailing list
nvo3@ietf.org
https://www.ietf.org/mailma= n/listinfo/nvo3

=A0

=A0

--047d7b6d9ce0075aa904eb2bc66b-- From lucy.yong@huawei.com Thu Nov 14 16:30:42 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D111E8150 for ; Thu, 14 Nov 2013 16:30:42 -0800 (PST) X-Quarantine-ID: <8+wKdWhnyGCU> X-Amavis-Modified: Mail body modified (defanged) by ietfa.amsl.com X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/related | application/x-ms-wmz,.gz,image001.wmz | .wmf,image001.wmz X-Spam-Flag: NO X-Spam-Score: -5.302 X-Spam-Level: X-Spam-Status: No, score=-5.302 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+wKdWhnyGCU for ; Thu, 14 Nov 2013 16:30:30 -0800 (PST) Content-Type: multipart/mixed; boundary="----------=_1384475442-1931-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECD11E8169 for ; Thu, 14 Nov 2013 16:30:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX28506; Fri, 15 Nov 2013 00:30:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 00:30:04 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 00:30:24 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 16:30:15 -0800 From: Lucy yong To: Vishwas Manral Date: Fri, 15 Nov 2013 00:30:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EDF24@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDED8@dfweml509-mbx.china.huawei.com> In-Reply-To: Cc: "Bocci, Matthew $Matthew$" , "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 00:30:42 -0000 This is a multi-part message in MIME format... ------------=_1384475442-1931-0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1384475442-1931-0 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Return-Path: Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECD11E8169 for ; Thu, 14 Nov 2013 16:30:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX28506; Fri, 15 Nov 2013 00:30:27 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 00:30:04 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 00:30:24 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 16:30:15 -0800 From: Lucy yong To: Vishwas Manral CC: "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" , Linda Dunbar Subject: RE: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4ZScgJ0/wT+VWESXUC9k1rWEoZolb0ew Date: Fri, 15 Nov 2013 00:30:14 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EDF24@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C070DA@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDE9B@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDED8@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.30] Content-Type: multipart/related; boundary="_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected --_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_" --_000_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. This is described in nvo3-nve draft. Figure 6 in the draft is shown = below. [cid:image002.png@01CEE167.8E410530] It describes L2VNx interconnecting with several networks. I am glad that we= are on the same page. Lucy From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, November 14, 2013 5:52 PM To: Lucy yong Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi Lucy/ Linda, What I am saying is that you will need a centralized gateway even in cases = you do some of the functionality that is distributed. We can talk of advantages of a disrtibuted + centralized model that are wel= l known. Ta distributed Layer-3 gateway allows traffic within the same tier= can be routed directly. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:45 PM, Lucy yong > wrote: Hi Vishwas, From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, November 14, 2013 5:40 PM To: Lucy yong Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Du= nbar Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi Lucy, I see the VPC as a branch of a bigger Infrastructure (in many cases), and t= he gateway that connects the same as an edge device. [Lucy] VPN is the case for a VN to interconnect with external network (ent= erprise) via WAN. For such case, a gateway is more proper. The architecture= give you option to use centralized gateway or distributed gateway dependin= g the applications. There are a lot of internal VNs in DC, when they need i= nterconnect, distributed GW make sense. As Linda said, both VMare and Micro= soft already implement these. If not use case, why do you do that? Lucy We need to connect this VPC securely - and IPsec as the technology when con= necting over the internet. I dont know if you can distribute IPsec function= ality. I know you need tecnologies like firewalls etc too, which I know can= be centrally managed yet be enforced in a distributed manner (not the gene= ral way to do it however). Same with the control plane that connects to the= peers in the Enterprise (we need a single control plane). I guess I am missing the point. Thanks, Vishwas On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong > wrote: Hi Vishwas, I do not disagree with what you said. A lot of applications do need a centr= alized gateway, especially a VN interconnecting with WAN and Internet. The = nvo3-nve draft gives the recommendations on the choice between a gateway an= d distributed gateway. VN within DC can benefit a lot from a distributed ga= teway. Some vender already implement these. Lucy From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Vishwas Manral Sent: Thursday, November 14, 2013 5:07 PM To: Linda Dunbar Cc: Bocci, Matthew (Matthew); nvo3@ietf.org Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi folks, In my view the distributed Gateway cannot do a lot of the centralized funct= ions required. We need a single place to terminate/ start IPsec connections - the most com= mon way to connect to a cloud. A lot of the control plane to talk to the ex= ternal world also needs to be centralized. Thanks, Vishwas On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar > wrote: Support WG adoption if the following comments can be addressed: Issues with the current writing of Distributed Gateway (Section 5.4): As described in Section 5.3, a Gateway does many things. However, I don't t= hink that a NVE, if taking on the responsibility of a distributed Gateway, = will do all the things that a conventional Gateway does (or the list of ite= ms mentioned in the Section 5.3). First, it might be too much to ask a NVE based gateway (especially Hypervis= or based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * Interface with external VPN domain (i.e. out of Virtual Networks), * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE (it is debatable if a NVE based distributed Gateway should take this r= esponsibility) The real functions performed by NVE, if designated as "distributed gateway"= , is more like Inter-VN relay (instead of full blown Gateway function). Second, when host "a" in VN-1 sends traffic to "b" in VN-2, the data packet= 's Ethernet header has "MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D = VN-1". Most implementations (Microsoft Window 8 and VM NSX) allocate a "fa= ke MAC" for all the NVE based distributed gateways to share, so that host "= a" can use the same Gateway-MAC when moved to another NVE. This again is di= fferent from the conventional gateways. Third, the issue of conventional gateway (i.e. a->b traffic to be routed at= gateway even if "a" & "b" are attached to the same NVE) is traffic "hairpi= nning", instead of triangular routing. Therefore, I suggest rewriting Section 5.4 as below: 5.4 Distributed Gateway (Re-write) The relaying of traffic from one VN to another, especially when Source and = Destination are attached to the same NVE, deserves special consideration. W= ith conventional Gateways, the traffic between TSes on different VNs has to= be traversed to the gateway, even if the Source and Destination are attach= ed to the save NVE, which causes traffic hairpinning and wasted bandwidth. As an optimization, it is desirable for individual NVEs to take over the in= ter-VN relay responsibilities that are traditionally done by conventional g= ateways to reduce or eliminate hairpinning issue. In order for NVEs to perf= orm inter-VN relay, the NVEs must have access to the policy information nee= ded to determine whether inter-VN communication is allowed. Those inter-VN = communication policies are most likely to come from NVA. However, it is not practical for NVEs to take over all functions of convent= ional gateways. In particular, it might be too much to ask a NVE based gateway (especially = Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE. The NVEs that are capable of performing inter-VN replaying are called "Dist= ributed Gateway" in this document. (Note: Inter-VN relaying capable NVE is = a more accurate term). The NVO3 architecture should support distributed gateways, at least allowin= g some NVEs, if not all, supporting the inter-VN relaying function, especia= lly when both source and destination are attached to the same NVE. Such su= pport requires the NVO3 control protocols include mechanisms for the mainte= nance and distribution of the inter-VN policy information to the NVEs that = are capable of performing inter-VN communications. ---------------------------------------- Thanks for considering my suggested text. Linda Dunbar From: nvo3-bounces@ietf.org [mailto:nvo3-boun= ces@ietf.org] On Behalf Of Bocci, Matthew (Ma= tthew) Sent: Wednesday, November 13, 2013 7:58 AM To: nvo3@ietf.org Subject: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-ar= ch-01.txt This email begins a two week poll to help the chairs judge if there is cons= ensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draf= t. 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. Please consider whether this draft takes the right basic approach, and is a= good basis for the work going forward (and potential future rechartering).= It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. If you are on the NVO3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree. This is described = in nvo3-nve draft. Figure 6 in the draft is shown below.

<= /p>
\s

<= /p>
It describes L2VNx interc= onnecting with several networks. I am glad that we are on the same page.

<= /p>
Lucy
<= /p>

From: Vishwas = Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, November 14, 2013 5:52 PM
To: Lucy yong
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi Lucy/ Linda,

What I am saying is that you will need a centralized= gateway even in cases you do some of the functionality that is distributed= .

We can talk of advantages of a disrtibuted + cen= tralized model that are well known. Ta distributed Layer-3 gateway allows t= raffic within the same tier can be routed directly.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:45 PM, Lucy yong <lucy.yong@huawei.com> wrote:

Hi Vishwas,

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:40 PM
To: Lucy yong
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org; Linda Dunbar

Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi Lucy,

I see the VPC as a branch of a bigger Infrastructure (in many case= s), and the gateway that connects the same as an edge device.

[Lucy] VPN is the case for = a VN to interconnect with external network (enterprise) via WAN. For such case, a gateway is more proper. The architecture give you option = to use centralized gateway or distributed gateway depending the application= s. There are a lot of internal VNs in DC, when they need interconnect, dist= ributed GW make sense. As Linda said, both VMare and Microsoft already implement these. If not use case, w= hy do you do that?

Lucy

We need to connect this VPC securely - and IPsec as the technology= when connecting over the internet. I dont know if you can distribute IPsec= functionality. I know you need tecnologies like firewalls etc too, which I know can be centrally managed yet be enfor= ced in a distributed manner (not the general way to do it however). Same wi= th the control plane that connects to the peers in the Enterprise (we need = a single control plane).

I guess I am missing the point.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 3:16 PM, Lucy yong <lucy.yong@huawei.com> wrote:<= o:p>

Hi Vishwas,

I do not disagree with what you said. A= lot of applications do need a centralized gateway, especially a VN interconnecting with WAN and Internet. The nvo3-nve draft gives the r= ecommendations on the choice between a gateway and distributed gateway. VN = within DC can benefit a lot from a distributed gateway. Some vender already= implement these.

Lucy

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Vishwas Manral
Sent: Thursday, November 14, 2013 5:07 PM
To: Linda Dunbar
Cc: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

Hi folks,

In my view the distributed Gateway cannot do a lot of the centrali= zed functions required.

We need a single place to terminate/ start IPsec connections - the= most common way to connect to a cloud. A lot of the control plane to talk = to the external world also needs to be centralized.

Thanks,

Vishwas

On Thu, Nov 14, 2013 at 2:24 PM, Linda Dunbar <linda.dunbar@huawei.com>= ; wrote:

Support WG adoption if the following comments can be addressed:

Issues with the current writing of Distributed Gateway (Section 5.= 4):

As described in Section 5.3, a Gateway does many things. However, = I don’t think that a NVE, if taking on the responsibility of a distri= buted Gateway, will do all the things that a conventional Gateway does (or the list of items mentioned in the Section= 5.3).

First, it might be too much to ask a NVE based gateway (especially= Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        Interface with external VPN domain (i.e. out of Virtual Networks), <= o:p>

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE (it is debatable if a NVE based distributed Gateway should ta= ke this responsibility)

The real functions performed by NVE, if designated as “distributed ga= teway”, is more like Inter-VN relay (instead of full blown Gateway function).=

Second, when host “a” in VN-1 sends traffic to “= b” in VN-2, the data packet’s Ethernet header has “MAC-DA= =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1”. Mos= t implementations (Microsoft Window 8 and VM NSX) allocate a “fake MAC” for all the NVE bas= ed distributed gateways to share, so that host “a” can use the = same Gateway-MAC when moved to another NVE. This again is different from th= e conventional gateways.

Third, the issue of conventional gateway (i.e. a->b traffic to = be routed at gateway even if “a” & “b” are atta= ched to the same NVE) is traffic “hairpinning”, instead of tria= ngular routing.

Therefore, I suggest rewriting Section 5.4 as below:

5.4 Distributed Gateway (Re-write)

The relaying of traffic from one VN to another, especially when So= urce and Destination are attached to the same NVE, deserves special conside= ration. With conventional Gateways, the traffic between TSes on different VNs has to be traversed to the gatew= ay, even if the Source and Destination are attached to the save NVE, which = causes traffic hairpinning and wasted bandwidth.

As an optimization, it is desirable for individual NVEs to take ov= er the inter-VN relay responsibilities that are traditionally done by conve= ntional gateways to reduce or eliminate hairpinning issue. In order for NVEs to perform inter-VN relay, the NVEs m= ust have access to the policy information needed to determine whether inter= -VN communication is allowed. Those inter-VN communication policies are mos= t likely to come from NVA.

However, it is not practical for NVEs to take over all functions o= f conventional gateways.

In particular, it might be too much to ask a NVE based gateway (es= pecially Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e. perform gateway functio= n to reach destinations outside the local VNs,

·        perform NAT on the source virtual addresses, or

·        relay traffic to a VN that doesn’t have any hosts attached to = the NVE.

The NVEs that are capable of performing inter-VN replaying are cal= led “Distributed Gateway” in this document. (Note: Inter-VN relaying capable NVE is a more accurate term). =

The NVO3 architecture should support distributed gateways, at leas= t allowing some NVEs, if not all, supporting the inter-VN relaying function= , especially when both source and destination are attached to the same NVE. Such support requires the NVO3 control= protocols include mechanisms for the maintenance and distribution of the i= nter-VN policy information to the NVEs that are capable of performing inter= -VN communications.

----------------------------------------

Thanks for considering my suggested text.

Linda Dunbar

From: nvo3-bounces@iet= f.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Bocci, Matthew (Matthew)

Sent: Wednesday, November 13, 2013 7:58 AM
To: nvo3@ietf.org=

Subject: [nvo3] Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt

This email begins a two week poll to help the chairs judge if there is= consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draft.

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

Please also send any comments on the draft to the NVO3 list.

Please consider whether this draft takes the right basic approach, and= is a good basis for the work going forward (and potential future rechartering). It does not have to be perfect at this stage.=

Coincidentally, we are also polling for knowledge of any IPR that appl= ies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for mor= e details).

If you are listed as a document author or contributor please respond t= o 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 o= r contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with I= ETF rules.

This poll closes on Friday 29th November 2013.

Regards

Matthew and Benson

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_-- --_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: application/x-ms-wmz; name="image001.wmz" Content-Description: image001.wmz Content-Disposition: inline; filename="image001.wmz"; size=5744; creation-date="Fri, 15 Nov 2013 00:30:14 GMT"; modification-date="Fri, 15 Nov 2013 00:30:14 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAAEC8Vdf4hc13W+sxrbkrK215KRV60t3sqJ7HQ8K2snNSn5YamyopiMNdtIlbbVWB7R FZUHFcmSstqtxospFhYlYDMWpAQTtq0JKbhDCoYWlD9EaUNdUojblPqP0phQ2kJN/yguKcRE/b53 39m5b+befefOSu5dn31v3n3vu+eee+53z7lvVv6nv/v+N01a7hz7gflyevb6r5fMJmM2vLvPmDGz bYIX+XvXnfeancmxZ760v8RLpmReTR8o80NizJt7IS1eN+YMRMrNrMjn3z5ozC8+iEcOPPMl3s1n ZvDQmNyQHT/YaszfbDfmPXx+wDa5ekfzKxvM6f1lsw1XxiGTkM2QCYgU9CH9/C8T0OtOY76Kz+eA Q6g3oBMOq+W1DL+81+zZb86ar5nz5nlzCr8TcwjHS6t3ak62mR++uy3V6TP/uM28/ffbzLd+7bXj PH8M59T1jX/AEZ+PONcTXH9hYdsc7+G9/EzTfVBaKP03rpfMBnwuvUR5NT2iD/95rzEbcSPk57g3 64aZgzFpzye/wJ6N3bVh09jYHWPl8s1fMu/vXzQ3aBsWecDts3H63IQuP31uYu4O3NvC+b/vuXfu MZyznTfwmfL+5bvTa3+Fc+o6v5BqZD6Fezg2vDd0vsW5h3bh/ShjR/DrWnpqf9EOLMS6+sore989 8Mpe1sxB+Ewdkvohjiwy5vM4TwI/n0ddjFAnihSrUV6nH8Lo1Il6hnSaRV0FwraJdxUixYc5vsFi 0r9DmC3UVT0/2v5RjxsQKT495uEE7BumZVCPi6irBOztjoP0X6tf0X3UvwOR4tP/PTg99d8IqUPK cjOO4i9NnA/aUdP2vIPla/svPmHbZpuhttkHa7vKkF+yjrpL8bXxnXF7D+d9qI1Z1LF/0icNbnK3 DrdipnO4xJbi0/cPMtyiuZIAhPpOQTh2OyCTECkydjtxASZIOdPlFepxTW7O6qkP23W55B185vN1 SBkiRfDnccH1Yfec+sUIdWpBpPjsQy6hTpj+QZ2I04FWmE833PZ5/RxEig//ZQATH0tjEJ8+584H tw33XNOfD8q6/nAOdMxT5wfx2YYUX39WwE/sD8e1DkFzq0XGcBZXqmbsN4hNvCLMf1ZiLgNLizkJ g+v01GMeUWIuI7bR6vmaErMa0fcfKDFj7Lnxrltvz6eUmDF6vqTEjLHn95SYMXr+rxIzRs/PgLg1 Ph+j5zklZhXRvNbn31Jixuj5H0rMGHt+ctOtt2dLienq+TbmvhQfJ7+RYd6Hm+oQHyefw3WuYfkf XtntXItbXznePtFwPuMSja82jXmCbWgwf6TETDK9iXkGIsVn24l7rJ5YooK2nUPdM8hfL5qTwDs1 sk0+jzRTY5MEqy9tMgWB248Uq53Dc1J8/Wbd50rFcYvrT9TJJ7RzCyLF195ptMX2iuKwI+awuYBu u+1o8B9EnKfBt3FYvh8a32McSXz8F/STWdRJTqbBZE6qwXS5oiNGxtFn5y9nmPSbOqTs3C/xWxPX OqidMUexL/O0WYTWrr1955r+PIpJpOvPT3/MNoj5oaOfrz/Ml4n5IO6rQ3z9eRnXL5sk7VFiGmYB c/Q8ZupJs2QeTfu4aD6N+hfN8Vyvn4UVfH29ndfYZ4oUX58/RJ6rs2Mt1Z94iwKIow/z8XGLibAk aMcm6jqwV93sg1+cxHl+ngzaRdMXcrauL6U9xNf0hZxNzKK+HE79wHrDBfjDoP7uZ01f3gZ/a/qS mN9K25pCf0bl72t4VopvPFn3FmwwjmMdUuaFrMg8n8dnl7/dc7fvmnPap5Xh8+DTiRxJnUBBQZ2I w6ikMrCO8vocRIoPn7k28dFMEH8WdYN7M8SW4sP9KMMF9Jq4Lre3BBBHH+Znyzpb2PXo6ZxvUt8i fO4DaGxdga07wHPHmPgUKT79uQ9A/CKbuGtTESb3ATSYMfk19wE0mDF6ch9AgxmTv3AfQIMZoyf3 ATSYMXpyH0CDWY3YA+E+gAZzGb5KP9X4J/cBNJgx9uQ+gAYzxp7cB9BgxujJfQANZoye3AfQYMbo yX0ADWaMntwH0GDG6Ml9AA1mjH9yH0CDGaMn9wE0mO46Re6X4uN5vs8hJswaXPuaqHP3r9311V1X 3HPO4TlpGEdf23yfw7aL1nOuYYKt4QbGuho7NaEXcTWYZ5SYru2L+s93TaH++78rYA1a5iHB+3hK q//ebdYMxz6oXi2+MeB7KepQFLPxvdRuINFeIhq7Mf7XjEWS4U7hSF/cAZmESJGYdicuwGypP23J zqF+OobXcJTi6yvrHoKz8fk6JLUjL6II/jzO3TjZPZd+a4+0T0LlsuLTiTEzdXoY94R0Yr86q1r1 zxjZufqFz5nrHzTHjPkzre4fx320D0WKzz5lcATtQzOG7DOLugRCnacgt9N/Xv2Y/Wce/ZHisw/9 hzqVcVPIPrSx9ZThfR7WUaT42rgBcmAbRWNQzfJeDSZzLg1mBfsQHFditkRJHH16MuciJqDXtIVd y16YJq6IBp85lwbf5lzJKrbozzak+PRnzqWxCWKGP9RiMufSYMbENsy5NJgxsQ1zLg1mTKzInEuD GaMncy4NJvR8XztGzLk0mFWwnBaTOZcGc9kc+LkWkzmXBjPGnsy5NJjLeCug1ZM5lwYzRk/mXBrM ZTCTVk/mXBrMGD2Zc2kwY+YRcy4NZtXh6iKuY86lwYzRkzmXBjPGnsy5NJhu3L8oJI+jj+eZcxET bhpcp5qoy+dc9jsn9C2f0N4diBRfux3EUmwXw7lmu1y/+DNtticnzAlve64ObLtovJt36+zYNL+i 5iO+Y9aMTWI+SufkFPRk33dAJiFSJPbfiQvjENpuS3ZewpF9uwaR4rNtWofAg8/XIWW5GUfBn8e5 tezwb9eemnPq9LLThk8nxoYMhuBuQZ1aqLOxId8I1sx8mifYmKtID+pAkeLTgTETdaAdQ3aZRZ07 f4ow+Z5Rg+nO8xt4RIpPT75nJOZWHEJ6XkTdZYwg7eR/z/h89p7RP0eL7Bmqpz2KbEJO0dmk/921 M3hEis8m9/PL0rAJTROyyRzqjuONK7PLZ3Hu64NG/73gJp3++hiIfKfBjPE97llpMKt4A01bsO9X IVJ8dub7XmIWfTf9i6n3HUvfzvJtNlnEZ2/fNc0Y1O+xepRwqEPKECnCYbO4kEDYxhTkdvLpC7DJ ONoI6TKPOtrA90P9YoT2IZ4U3ziRT6kT7RLSiTjrzbXZRmmNNmZRF/P+hbm2BrMCXqPN2IcWRIrP Fsy1iYn/1rSFjWHyY6HB57qhwbe59jA+25Di05+5tsYm7jwuwmSurcFETFsVOxdhMtfWYLprXREm c20NJvRMv4dFvCJM5toazBg9mWtrMJcdri3Sk7m2BjNmfjHX1mDCnqvzq0hP5toazJjv5TLX1mDG 6MlcW4MZM+7MtTWYMXoy19ZgxujJXFuDGfN9BubaGswYPZlrazBj7MlcW4MZoydzbQ1mBRGQ8Oei kDyOPp5nXExMuGlwnWqiLp9r59cTtuUK5+5ViBRfu4w92W5RTNfPtZ9Dvk3ZnWvLbXfwnHoU8Qjf v2lsyhiK+FMQuOBty5F/ApuMA78OKUOkSHw5jwu+eE70G7TBWp9pm4SBVFZ848SYjjo9jHtCOl1D Xf9NW/8sca6GdLbXnzL70wxpST22a/XrVtXRPhQpPvvw/RvtQzOG7DOLusSYP6ZeU5Db6T9Hyh+v /6QdR59YfPah/1CnHagP2Ydc0fea/pnOf4bf2Q2Ov+q7AtDhzVaexwZx1vOZflTEieRi2qqIE/Nc bD9pdaMeFCm+MXt83OpR5NMVgLBdDSa/H8K+FWEmGebtnid/DV2gUtAn51GXBH7Y5xihfVoQKT6b c55QJ1BJUCficHaI3UUHXp8TcBx9+PxuMPHRTBB/FnX0JheX2FJ8uMydiVvCTXUITleLrFmzuCI6 E68FkeLDZO6ssYX1/PxYaPCZO2vw15M7a2wSE/sxd9ZgxsSozJ01mDF6MnfWYMboydxZgxmjJ3Nn DWaMnsydNZgxejJ31mDG6MncWYMZoydzZw1mjJ7MnTWYMXoyd9ZgxujJ3FmDGaMnc2cNZoyezJ01 mDF6MnfWYMboydxZg+nq2ZIFBUffmsLcmZijrq+LBfizCNqID5cNroNN1OVjt/zaJeuuHLmWzRW0 y3cjbLdoXa8gcnBxiS3FZy/Ga5oxSABC3CkI3GukvPgcnpPi04V1T2D9A2UHbUs7ufGa9HXwyH63 IFJ87fFvcdleka9kf4u7ale2pcHn3+Jq8EPxTdHYMZYkfkxMVoQ5DmNoMN052REj4+izM/8Wl5j0 mzqk7NwvsWMT19y/xV1CJEk7ryXsS1F/+I48tj83gCvF1x++IyfmVtwU6s9F1Nl35DPwV9/f4i79 v74jj7XJVTEIjj6b8B05MYty2gosJn9vvQTLdBTjLD7Aseb8l+LTg3xGPYp4cjD/aQkojj7cf81w R+WKIj/ld3g0Y5JAP9pjCsL5tAMyCZEi82knLkDltC9bsnPyBPW4BpHi6yvrvgMb8vk6pMwLWRH8 eXx2edg9p34xQp1aECk+nch11KnI/uvJm4kf6zfUXYpPb+bNxKXtQ7acRV1s3qyxRWhdaaE9KT6d mTdr8NeTN2ts4q4xRXZm3qzBjIlPmTdrMGP0ZN6swYzRk3mzBjNGT+bNGswYPZk3azBj9GTerMGM 0ZN5swazakpbyHP0zSL/ZN6swVyO+O4w82YNJuz5gFZP5s0azBh7Mm/WYMKeY1o9mTdrMKHnr2ox mTdrMGO/363BjLEn82YNpjuPWkL4OPo4n3kzMUddXxcL8Jk3Ex8uG1wHm6i7HXkz2y1a10fJmzVj kKBP9L/bHa9tB1+Po506BMv3arld8VoR3zFeo04xcc/VVa39PsrclJhFOUbeh+wnjoFG2K8bBXow /6MeW3FfyN4XUSffaXBj48HzCkZLo5f2HupfZEe+f/w47FjkI4+Px/tIESbzP43fJbATbbqeefkW npfi41TW/T78ZALHOqQMkSLz8gwuDPrE4GfquR6hzcY5EbPi0/UG5hZ1TXBPSNevo+4Q/l2sA2ZP oc6DfbDPzayrH+uxgTxLW1BOQ/j/IPi+cf8fBLiIwnF6Mz2z3xXITr3rJr+vT7vRvCG7zaIugVCH KchGyA7IJESK+MNOXBiHcIw+lZ3fY8xL7jk+m/shLBMQnlPnDaWN6d8ofIKLXXo2jv8Pw51jrJsu Tab/dtzPxj68yVpjXqPKpsz/R8HZr51//tT55NCpS7w0VPh8FXf7jmOlUtrSJrY59hB+zWyGSdAH 3o29XGiQOOUuRAAbIfanf3Y37uWTR2HJ/pMV3PsLWc0J8H6/prpahrE24l+7s2jfBkf3n6k4etjT ikeTvk79swcyvGlYuI8nKvTvs2f3ZXefLpWdu9F6RXrPEWRvr5TGnDuqVdZL3eu5uso07SZW+qOS a6UETzFu25FiPYaRYpS1rcyxx0l69ZHSzZvUnONlR4neFztKE3hmZvMkRmmDo3cnqVRsz+/P6s9g D3/QTtJ3HgXnGzmcStKBBYhk+zlp/jTnDVWn5u1czbJTcz1X4z7zl7ma5VV7Tpq/zdW4z7ybq3Hb eS9X4z7z41yN+8y/5Wqqjgb/latxn/mfXI3bzke5GveZDTn/cJ/ZnKtxbbAlV+M+sz1X47aT5Gr4 DHmKHvJI6T7HAzpJVjrJ7vSs5GcBdyaJD+R9vemM9J/kWucsYETG1r9busNp/ZlTF0+eSeeWxRfk Hw09HzOLrK/vQouur9t+Dvv6LkSD7pw5cvhCYm1g58IufJfXrQe3oJ4/VttdHmaUmhM5P+AoWL7a hX9b0OWrTn3m6KGnF1MWcu0vON8awNlofjm15y7zbawd/fl8OanPJI2FU+fPnFx69OihxU8nLx63 0M92rM4uujum4VrR4WxuTNiXbZkOC/CZvg6do/V9h052Mt4hbp83dpm8Z7go382hHD51Ht24sMrL Vj/R5Sc5XRK0EOMfD6V61/B7NJatDbPsgrWlXSFq+Jc8h1cPq3vN/G5uLLmOTmT6/N6gny3YXkv9 ECejvm/bWpCTaybEyTUT4uSaCXFyLcjJNRPi5Br+707uushxF3uEOLlmQpxcMyFOrpkQJ9dMiJNr iM5CuoU4uWZCnFwzIU7GX+QG23kkV8PYx/JEDdGhyxOhuEb87nQ+MknoP2LnhVwbTXiO1Cznati6 4PmiIPHG10suK1amd+cihNrATB8tEtqHmRE7R/fimZnN+zBHH3ZZKUGxi93qksdLWanPHDyWziU7 43TM6OdSa9V95qsl16tG46jGCP23MW4D/XdjXHR6lZGthg38eyWuhv052QhyVMMMcVS2Zk2kVm+Y IY5CfZ+jGkGOagQ5qhHkqEaQoxpBjmoEOaoR5KiGCXFUI8hRjSBHNYIc1QhyVCPIUQ0T4qhGkKMa QY5qBDmqgbjR9RayhF3/G+Aod/33c5Tls4Y5meMz5n3T3RMnBmedeOg3c232Oath8rHnaOzSHGF2 bU/9vInZtSnPLp16bf7gsWSYOWxfmpgZg/aTmuHozmbJTUR3W51WEN3VnOjueUR3GIVB2w1rIGtA EyPl6sAsx8blTfNELi4/vnDw2LPdPrZo+psDz/eRT+Zq6B3yzOlcDVnG7hs0zdmSu2/wxcvJsX2H kheTxMergvbnObTRxr09wrhbVm0Xsmo7yKrtIKu2C1i1XcCq7SCrtoOs2g6yajvIqu0gq7aDrNoO smo7yKrtIKu2g6zaDrJqO8iq7SCrtoOs2g6yajvIqu0gq7aDrNr2s+qJ/Oy2M6kNVnVnUsqqz00/ N73bxw12JrVvSXx2aYSZtDdl0Etx8dlT+29xfHbplsRnV0bo/2fT/l9B/+2uoN2JTYPSUHy6Grn5 mLHomvWRK/An10dkla5W8x5lPcb6yBWTzxmYq0pNPmcYjYe7I1hvIrVeF9Zzsw/sc2b9sJlLd40M vBvk4e4wD6d7U7Ir2h3m4VzO0w3ycDfIw90gD3eDPNwN8nA3yMPdIA93gzzcDfJwN8jD3SAPd4M8 3A3ycDfIw90gD3eDPNz18LD40yO5bJb+ZOeVjXG75gu+GHcgbhXfO5vPwrHzJvOma9Y3b+zO5grm gGZnc6VgZ3OlYGdzBbPMjRf7838F/+aeW8Oozkb4K96dzaXAzuaKCcW+K8Oxr7uzuRQb+654Yl/L jCuIfV1mrKQbpktJJ9M5z692jFcwjsM7fNaXVszXc76E/eSjZFXxgZVbkrv04AOxOyNWv94wdx61 a4DtW28N7uwFubM3zJ1pr4U7e8PciXq2a1eUXpA7e0Hu7AW5sxfkzl6QO3tB7uwFubMX5M5ekDt7 Qe7sBbmzF+TOXpA7e0Hu7AW5sxfkzl6QO3uIYQfW4mxkLXf2/Nw5wAjie2Hu7K2TOx/CjJnZfH2E eWM99LqHDS2DXAcbugzSj636GXT/zOb21wf4jTF7vjCHtj++CK1/TXSIj++uB+O76+u09cOprd/B 7wln/yLfP+b5eW4d7O/nMpQLJnFQDh09sGcQST6jbmZtzOJaO9rvmPxehzbCfRA6/2xsDKsjy/fS t/ylsbGdh5cuXDz1O+ZJY56E9EsJn1HS/lVLdk3lke+zjPk/aJH+VLiDAAA= --_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=5122; creation-date="Fri, 15 Nov 2013 00:30:14 GMT"; modification-date="Fri, 15 Nov 2013 00:30:14 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAAEQCAMAAACUWQz0AAAAAXNSR0ICQMB9xQAAAHVQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKDQgEAAADCAoNBAADCAMAAAMIDQoIAwMIBAAEAwMA AAMDCggEBAYIAwAABAQABAgNAwAECAYDCAMDAwADDQgKAwMDBAQECAgIAwQECgsKAAQECAYEAwQK wy1i9gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAS9ElEQVR42u2di5qjOJJGbZxkYsqDnbkzVU1NVlfPZff9H3HR XYIwBmynwZz/687CGAdB6BAIIaTNBiGEEEIIIYQQQmheyrPn29Nsne232vftooIHszALszALszAL szD7Vdq9bLVe3zaFWdpvwlJ3oX+pb/toT0sKSziSYYfZt31/CIR9LjN4z5X9yLPkWZiFWZiF2dkz W26/HWAWZmEWIYQQQgghhBBCCKGbaPe3Ka1X+X69EaN99gudFa1Oo28a6RvTs2HhD9WkMF5fYPex +pTMToWvjXpl+tBU22O08vS++OwBs/NjdupFvs367uN/Guvl3xNKYRZmb2918jW+Dfvu4x+qT+l3 RWlhei7aTow68Z5+2E6SMHuN1WrbSTHCqumbTbf/hcxOv5dq0b77eKuy07vKrNpmqaoKrTxbHJ+S 2b7Ox8P6fJ/romz3FLb3/wVbbpW0rneVsE4wFlb1uvGFzE5Ps23cG2bL1z/qhtJmSa0o9x1m7Ufy 7DVWi+SO4dyq6ZtN/uFXMXtNk1XKuyK1en1rsNTVAFMnCMyaTPKcefZrmV1UWO5g9Zo02wLeZteQ Z+0nh2y9Ic/C7A2sXvdkICE+MLspdTrNVZ79qe7E9vbb3Qt5FmavtHpdmk2QVxWCvbqhVJ3Cc18P UEt6p6Va9f1H8l7mMzG79D0thtlrH8BeyzzMwuxThQAhhBBCCCGEEEIIIfQItZsR1TOWe7YsTrZ/ +T2R8njRSNE/IFHnkdFYb/OwudQXcXpgF9zaG3Xj0YX4+s/sygPX6/TDvq3uWfGjbgxnxvib+nvM 1TfmcaHZTm/Yb9U97XY0deynqjpGJxScelAU3N4Gr+P4/eyO61r5jpTWfsdbMRhiLCIfzzKb+Ggt FK4/Zy66LXcjHVf4j2P2vTm+Wv+je++U25sw63tdmI+6S5D5Qj1xLPUpYlOU0MVuyEskXfvxiZjZ P1cxmx83sduJ172Jtqjb9jveysHo7WnRk2eDtdAtq9wbN2S329YmFP4cmC1DEanz8vWPy4lqALM2 fh6sz4P6WGUps81Z/u3Q7NWkhiF9ZLr22xydfh1UJ4/aJBmfeJp0VpeuE0jmIDcdP7Qb6pO2V2Wb 2O3gdextKQygXWTnmPXeysFwsROj0cNssBZ2VNSmQL39+AWZjrWo8F2kQqCEMEZRHArL3fJsfNLd jFm7rM57HZtyry6paZ6t9r1vb/QymxARPjY7MItVHb0xogqlAfPPztmh9t5w7gvQLAe3Y6+Dt26r 4cyaZTEYfnspGn31WW/N70iV6OehHWxnVM6z4YpmIuUDJYXRfTkYlpvKXcpUlUYPUBp6/PRMBCDO pyAyqypxLr/ofZXmdZS0blAci/3mklWRWWc/Pg/db9T/6RsjG/N6TNeq/pku08pcVG0GdW4nXhtv k8IeyKz1VgxG8Mfb7zAbh8V/5635HemD37eDHWpR5qfBmCv8OFJpoFphdF8+pntYEUXd1AL17cCA us3FPKvO9JCJPg9mbamIr9v12ep41mrrDuyc/W6e1ctFndxqRsfr9hTeHVEI2pqGv+pbtxOvvbcS s/4urMVs4q0UjOjIu9HobTdw1tyOzBG9xm7HL8jIRacKP45UCJQQRv/lUFjuwWxRh1R0rjAmMFuG saXzzNxKqX2Ux5TZ5m46b5d0354k+2meM3QUma73xLWHDrPxuyPNjdenMejpsm7HXgdvx9QNEm+l YITthWj0MuusuR3ZK0oW7CcvyHSs+cKPIxUls24Y40w3CJa7MKvDqT6Yw69uwmwevXW8+/h98OdF tY2Z1VdMW6CjmM2Ft5r1CyG23eD0U98ehDdGJGajd0d2L3+5s7ZyWdi4HXkdeTvmHizxVgpGuCcU otHLrLPmdmTOO31rbe0nL8h0mfWFH0UqwrIbRvflYFhuJ3PF0BWU7+7GUr9dcVXdwLY1NjWkahtd kQr/ykZtmHJtkuXW3CnrqvwAZs/YD1fW0NBZGKj8GyOF+0FUMfTvjqgNQyZ0VrXbqdfeW7Gtq4WZ 7G07GKF9Vo5G/zMFbc3tKDrC36l9e5BdZn3h+0gVSWRbYQxfDoZlxrpTJ/0vewUp7GnI3YX0TEFo n71FPHkOtjBmhbuw+ygGddqz291LeA529et+PLtFlxDcDnvoixBCCCGEELpOjMkxLWyMyfE43XDs o7Uze/2k7IzXNcxqAt3osK80zcLsQ5lNqBsd9rXOtwSzj2Q2wW5s2NeaZh/JLPMppNyNDftqp7Ub M5+C2Jv7+eZTEELQ23VeWjU4LPl+TNhJsw/OsxvmU0jIGxn29c4eSn32isO8SbD308K+3jQLs49m NrA3JOzl1vUNXvEkzTD7YGYDfKOYXXGa5TnYwzWNvhWnWZhFCCGEEEIIIYQQQgihB2lsq+n0VtZn aZ+99+wSCGZvImn2Bz3e67/e1chiR0iG2fmpM5+CHvnw9OPohnQsV/w0FWZnzazn8/MQvlGJF2Zh dsbMquVoOMXPw+n3O/0pYHbGzJpaQRjk+fOQZ5+HgoHtYHaOzIb5FFSe1W9q7TdFraiFWZidK7Nu PoUwdnz+7/emNvu53k7YMDtvZv18CnYKMrX0O4uHWUYwOwdJ8ynkZoWdDq44LvjwYPYJmUUwixBC CCGEEEIIIYRuqTUPHhOHgXFkZqbdi+s8Hp6t2aU1D9I1lKTJ87Myxtx0Yyc3b/im2ruHa26JRAuz c2Q2d2lWYVrtkyUSLczOkdnCptlS/bt7qeMlEu2DmV3NHCDjjFV9W5No++IpzErBHCDj5wA5F43J 5UWifXDdYB1zgNzSGImW+uwXYHZjYyRamJ0Ls2F6j16RaGF2acySaHkOtjiRaGEWIYQQQgghhBBC qKOKhoxlatwzBdXjI/T2qG40GntqdeQP+10ojxeZLYYeRL7d7i9vwokwA2bDVAJmYKo84JVH0wok swpIVncvCT/BbNuqOyHsTq/wX7e/mzPC9q+qtYsJetHgx2Hn0inU3pU4n8KQJ4DV/mxUImOF6w2W i27LPsKs/TIZlj0alF1/76YVSGYVEEuunaRSs+lQmKcfmf1zFbP5MWzT7L/U/bfaiVVKtNJgsq1d yfMpDHpqXYSzsR2V2Fi5L2yqkNzerHbA2/HMWg6aLJCp7x1ryawCg0ouMZsfBY5Ovw5qP7VJMj7x NCm6Ls3YhN6q2kQloib5fTuoT9oPc/k3HKihY/dqReGuDvanpZCwinMHEPyR51MY1tMivJ3YSd6R saI2VZvI7Us+wmyX2aa0jh4xVZ8NV9Z4VoGRzDqrna+aYjGLVW0ykuWrUGD++da2qt6bMqNw28Fh fx18RlJryr1y15W1x/3XYTiz3p8z8ykM7R1U2jOm810wpk41fWKkbsPs+DyrwLBrmqiFaQXcrALi 2wwX82w6fKuzqn5ji89ubbJZsRf91z/Tlqo6zqDqR5pb80JCi1nzppXEQ+K/2976c2Y+BWe0+55C aqxxUXfjEph1xvTBmzpC7DbMDmfWXwubeNoCy7NoWoF4VgHpati5g0/NJrWzKM/q5cLchLjRiqON A3juS4WgnffIX/U/D9piqV6cqYcwK93hRNFQ/sjzKYzLs0JUvDFzRK8dt3t9hNkzzGZRng3TCsSz CoyoG3hms24OMVftIlOnSJqV28wa7syp1NRbrFF/1c8zl7CaOsJ1dQPnz5n5FK6tzwZj9oqStd0m z45iVl92dauURkC/ie+nFYhnFRjFbLAaF+retxucfv6hm8RCRVpg9uPNZ63dy1/uAuweG+w+fh8s s6FVOZ9yD9b2pz2fwqAjz7f12e+8sXBOpG7D7ND2WTNzQO7fIFW1s2OuamduWoF4VoEBJReZzaX3 UqP2WfvGf+6u/oWrJERVRG3uuxmCJfcd/n1rROEmQKjtmRC/Iiu1dfUdQOxPez6FQe2zx574W2Oq ZmCP8HfkNsxuxr9bc8WevuydkLCnIX36pWcKQ9pnbxOyK6JC++zdmRXuN+6jGNTy8j6FdCVPnHSX Z7eTo8LkTs+jYjvsoS9CCCGEEEIIITRGKx2egzE5llx46xwGifG67n+C3evI1zoKEswul9m1jjYH s4tldrWDzTGfwtzmUxhudq2DejKfwrLmUyDNMp/CmXULyLPrHTuZ+uz9MbvLka946GSYnQuz3bHp hdHqw6oVD1EPs8tkds0j1PMcbKHltuKZQGAWIYTQiuRGHtmG1jdhFUIIIYQQQmixGj3uSfZVe0II Zq+Q7Z7lRgh//c/HmzyfAoLZ2UgPU1hlZgy4cvv6Js+ngGB2Xszu/nawQ2z+fJPnU0AwOy9mN8W/ 3ZD0Z+ZTQDA7M2bzwKw8nwKC2ZkxW3x36fXMfAoIZmfG7OehqpMV7fkUEMzOi9nmGExn6/z1TZ5P AcHsTGTbZxWmup+Vm56hM58CglmEYBYhhBBCCCGEEEIIPato60Iw+xTMfpmznMkwC7MwC7MwC7Mw C7Mwe2PddD6Fvu3vN9cCzK6M2S91ljwLszALszALszALszALswhmYRYhhBBCCCGEEEIILVHMHfpY Z2kBvE3M+uK44nnFb3kA3hbMwizMwizMwizMelXbzqwZwqrpm023D7OLYlbopO8Xon71PZ30z/W+ t3sK2/v/gi23SlrXu0pYJxgLq3rdGBmWse8pJAGC2UXlWV2yxwGrpm82+YfkWZhdWunALMzCLMzC LMzC7BPtaUnOwizMwixCCCGEEEIIIYQQitVuf1GzEt+zSWayfdXbpP+H5eWZk4vsq93erL6JS89z bae6VoX4+s8x8Tj7wKfURmu9g7oxnBnjb+rvMVffqB3v7XZ6w36ru5eEn679VFXH6ITCVxPXB7e3 wes4fj+7w79W0pCwF8MS2xfDIrh91v/rinXuzL43uaLW/+xeahWtmzDbWPt4Cx+VeftFrovkGFJU 14Zotd1NtWs/LrHM/rmK2fy4id1OvO5NtEU9JSyp/UGPwM8ze1WxLofZMhSROk1f/7icqAYwa9Li 3oP1eVAfqyxltskF3w5qt/vNwMf1Xfttjk6/DrlKViZ3Fa7PaZPD6tJkIG9Vp6V9y41NlW1it4PX 8WalkFSLSWFJoiKEZSKzoViHlurS8qwJrDk1b8asXVbpR0ew3KtLapJnG8A2yWkzhtkEhPCx2YFZ rGqTpy1fhQLhz06f6eKYumGWg9uR19FmbqsJzLbCkkRFCMs1eXZUqS5BhT+orSpNU5GzXw3qMC91 0o8KR9XdXFrR+ypN1/6kbqCIaeC6YFVk1tmPC8z9RueXd7e1ycfFXjwT9M+sG5tAuHc79jpsFs70 NrPB/+igesKSRKUVFoHZ+IUF6V2HTrGGUn0iZk0g/b3CgBrQxTyragIhE30ezNpSEV+nzKqyL8/w 2b4DO2e/m2f1clEn9yTR8bo9mfI/pm74q751O/Y6bCYxK92FXQ5LEhUhLGPyrFisQ0t1Qcyaf3yA xMKYwGz57RC+MrdSah/lsXUP1tzxfB4uWRWYjeynec5AUWT6AhnXHjrMmkM16Tm44aGybqdeu80m 1Q3EsCT2hbBMZDYt1iGluiRmdRTVB0NWdRNmc5Vy7NV69/H74ANYbbNWrvtrf9Fql9nYfkjLe99u cPqp7zpsTVnOs9qWzeXBDXsP5t1OvPabTboHE8OS2BfCMpVZV6yDS3X2MpdF/bLnd3v3vMm319YN bANjU4+qwjXZ1s60+Tq6XNmGyPzbYTCzZ+x7Re2zhYEqd5sV7gdR3U+b+/7DvMvqE2DurGq3I69j b8W2rilhie2LYRnFrFCsg0t1fZr8kCbfT/3ytv77PfXetNjNpGcKYvvsDfy5PsTotsz239YKd2H3 UexGz7Nbt5mQUncvt5waUQoLzM5CxXbY09Z5uPFl3s4kLAghhBBCCCGEEEJrEOPIPNZZGmpvEzPG mGOMOZiFWZiFWZiF2QcwyxwgMHsTZpkDZHRYmANkPXl2wxwgMLs8Zp8mLDALszCLYBZmn5rZpe9p Sc7CLMzCLEIIIYQQQgghhNB6RVvXY52lrQtmYRZmYZaowCxhgdnpGtaHW/pu7Pbn+oHPPCzD+nCP 7fN9sXc8mst5Tp5dfFRglrDALMzCLMzCLFFBCCGEEEIIIYQQQgghhBBar/xE3ej0g2m/56DcTPC+ 3f73RXWbUx3ojm5G+ExN+v7tf1dUTD4aWyEYpx/1ZvcCtI9XqUdnVdNvm4fjamr33Uc04G+5plLy 0RCCoVed3kHm8aW0rzLDrCmOz8OqmXXROBOMZgOQmUEpnX6+aWY3Rd18VHmmKSZTUqsrpRANORhh CT2ylPR0A5mlUxWVfv/kdaXMumiIwVBVWjSHUtq91JrZ5lJo8sia86yPhhCM068DwMyjlJproGE2 z3INaHIFXBuzLhrdYJTfQHY2pbSpTLvj7uP3IRTT6f/WyayNRicYuaoh0G7weOVb0yRpp/fSsxK5 Jsn9xrVVrqXpIIlGOxiV/vcIMwghhBBCCM1f/w9cuwqC1rYGGQAAAABJRU5ErkJggg== --_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_ Content-Type: application/octet-stream; name="oledata.mso" Content-Description: oledata.mso Content-Disposition: inline; filename="oledata.mso"; size=29411; creation-date="Fri, 15 Nov 2013 00:30:14 GMT"; modification-date="Fri, 15 Nov 2013 00:30:14 GMT" Content-ID: Content-Transfer-Encoding: base64 AHgAAHic7NR1TJ3Ruidg3KG4Fiha3F2KW2lxd3d31+K+i1Pc3d3dvTgbd3dnc/eZuTc5uZPMnZOZ fya5v5Una+WzN1/elTUzjbGVW0u4DfGf8g0CGgL0gQgB90/XIP/d/wg6BPj+x8c/lv8x/yMf/53/ r/IO9o/+QYN7BwMGC/aPnsODIYAhgiGBIYOhgKGCoYF9+p9bAAIDDBMMCwwbDAcMFwwPDB+MAIwQ jAjsMxgxGAkYKdgXMDIwcjAKMEowKjBqsK9gNGC0YHRg9GAMYIxgTGDMYCxgrGBsYOxgHGCcYFxg 3GA8YLxgfP++R/87/2uUIOzBwwXcCwkIO/DsBOH5n4+C/21wwTvmP74F+V88q7CwCJW+PQX5z+eF PriDHODBCe7UP7CA16z/Qn18CCjIf/6f/5N3oMCkHP+FIv9F/tX6/6/zf1U/FALC489ZmquK9lrX ZbBsFDbSIL2G46dBQ7xIWUdGNFS9dd1I7cAdRuylnXg4xo2tC7X14LD4jAvfKW/vP7XD3o9Zj0u+ 7v7s35wrJyiNK1v92tQkQ0krfEDfG5Ge8CKgWSDcpQUgHrIPZkC9l+RwEDMf1yC0CHGQM+FzM0gb MXDnQt4g1+Zp/ICHxkFxK7dHClzbFxuGBkER/X0bKgCeRlohPs8jPAgFljdSioZGQSEvR1QkJggO lhGJDztOUUDkGnuQHfuOBl+BJc9AtDd6hxcJF7uCZlmhJn9LuDciCBmWG4kEu4PmSeEqH10YUpws fAcWiQy7j0ZcITwP/RXYDAmBiA2gKQBtd38oF6I5iHfqKDbFQ/LkNE1BVPv/hP2QSoCuAalPfIzB p323Mz/EBUQqmi9aduwv8/iDqhAX8L2GTtAJ4ayErkidLSBUA4h7brpdJoSQSZNCQB1ZH2eXJCDj cjgW2FRoG8X8+25X3AEIlwZ93quldFD98LC44d778Dc4q3czCKIAgZMT7VyGa32c0e5akP7h63QH aLrlQ/uDPeRBiuDjMST2ul3oo/IjS0l5oMcnfAyu2+pdGWLwfs28lialpAekOus4i6rHx9eixddC aO3Fq9mG7+i1uiY42i/uDzr+mLUELfp7L1iilrk4YvnnC5F9r/AC2aGfH4cx87jUDc4tBRwX8t1I v648H+9rPXuuFxNcKqNmj0ajveMTOuGf2htM4rW8qMwK3Qbd0Nv9yBQt+hHXgrMUocHB59fFEd7T h/ZV+tmleqKxN+RJk/aqtDXvzrRdPciotkGHd0jW+E2wKaceKIXsscSwdx5b90z+B0dpHfuglrjY vDY1C0ee7Wq3/CZrttHP13mudFoelAhZz129NC3Nm2G+UFMgDDCxeMHZkal4P232gIbWYku/gdHe VAqfPW1U3rt8tuz4FfEC+6FWhf57/mlwg5U86JHrwWfgpDlxOf0EUU7dbkmSm/Ox9g9cTb9UF6wC +Zr5kXWBQGUSbgNFKxKtovRGHgXQjpKy0m0Whpc9LT4Rz/uA7GNUlmAHl6PKliZSk4GGABuWrfD6 D76nq2lgBEicOKCSX+SyAjrMLwkb1356vY2NIu/lyexLqsOP4zCj+eF8jhbrLbKVpRzrllFDiCGM 0eWiMj9hHlP7yiw0NhmP48WLO3W8aHGjN1nseSolzj4Fb7qj7hc3HRdjc1l+PKYp/d3N2ddmP1pq Sz1IsRO/J4zFOsvs7C0BUH3tClXrNMn0A4vo/OOsAIK/T5p1yJ6QpWKGf71nE2cJXxIBgJdMiTJS 17SM+9mSel7cbWVxvouVUOpn9fQXiuV0YbcSwr0tnkGq9KftegsUec0NLdsW7OAndvquE5/+mi61 yWQYQk+BmKcB0r+HrKaMlZ3mfPgExyHOXjBfTilGX/R0c66xcxO+JAl1LcxOGFBqksaW7jIUE5Rn +sQ5V6CO8/InET+yGLvlafJ+c4BN5PZkiuGIjUU2Hn6NxuNFuXUd75vxF9vjyzhc0Ka6eSol4W/N /vRmKs24pO3Y0B2JkaMztva1RF6L1R+YspPnycOn7fCOQYMbe2D3UJL3WL76zm4xoyAS/ODfWfaR Xe4DVYZJLhPtjBIrAOjY6ihWHTLem+yHMcSxl7oEoC6UY8ze3BjClSVhCj9sAjU1XouNIQ/j6BAH +LW8viV05IfDOCCP/SqI/3yOInrraCl8VtU0QEqzSnGe+X7S2dcgQ8rfHhMM3ZvNcZPq5tzd4oVh 0u6/IdKeDL+CI0FHeNe94rUetPE5SV0fPt+bukGsNW66Rb/VqZMdag3/F80pZIg4u2/K7NAcKeWk AWPJ5O64BFM25qOALwH1ybILmhPg7dsl9dptwjtkJnOE6EgY8OYMqb5ExahJR2clJVhntyoRY+PL pi/erNiVr9vuZXWrKfbmUrlROkyIPaECJbubqIo/NFDqiiYGUIHKWg0st0QZOTcr9vRqU0zyQX6i /wR9xCE4KQHEvQC8XSfuuX96rbdnPFrlj3XG2hz0/VTyTQKZbv8wfYlqjeTZ5JHIWiSLl7Z5L4OT 2skzXRPewXUL574yVSirEWHjrPP6MqbH5GaDkQWlicXbr1MZ2ThF8WygroOEt7MU5Xd+uWe3J9vO +baV6MBUD4t4tupv125yRHd7N8Tt/DKK+07lgyRnk3YOc5b8z7SyLq/8x3GIj/mDK3sI/CGLtMpx r5Np7XaPN2X6RYDj2GvTklPE5osI7uWrlc79q4IMg9U4xOk+6CJalvSeXwh7GFxv6pLNKjNLRsnw +eUohqILoSiuA7X3r5A4FpvdV399KJ6mylOfq2xinI81/6A5CrT3PBGR8NVVsFiu22p9V15TxJNK xbCsVSJOkvIqNmVSiVBH5MJhRx9228FnI64l/zufWv2rR5R7PWVnAqRV4flLL3BjqdOXBfOPxDZs d1SGS8x5/rbSI9vOAhtfB35QCAxkY1I6EQyAEYfSl3xYCDl1MU9K2q8BV0khYPt7fUF9SCJaHnGn l227ulR4K2oJCnVS2/e5e9rQzHP9s5ZGmiUA7O6UiFZm9l9ldXVT1Rkm2pxONaq5tnBz5JkTAEq+ JnZSaeRbF8U6VVYgHpfqirN7Hesx5zqdJQgf06Vn7b3euvMjHYSSkH2k3tZ9+vwzj0LiB0VnvTa+ 2NXpQMTDPFdy4Zn29egpNL8LVgC0TP0NrvJg2TJsAh06MGjk+SCvBVsx9pe9KuphGVJeN5ZGJLmK oJj+qil3bze38xIlnVcMAcULyPxGcIkQsXQf3rkFi4S1pqG9oX2yrHDWAkoQwYnWXi4a8AaIyH0Z Omp7XDCJnQBlvJBxVg0LQDfVsZ7AWxn5CU7rG6/AuiFVI0tjcx7UQBOc1tgKJLI7hcYnyYW/zQnv 8xjbr/Y0RH9lkbLEbT2U2PxukBQn8Iwp0AFUI0VrhnPdIa17hVPgd7CQzSU1gQ9sQ6gRWm5POvKp ftHql3k29CsNrINOxHny8vBTs+7RkoFs77JFXveCRtGudDH5Wug5Y3K/6EovSWIojv0oLWggv5zG kJg5QVkN4ArpOcqEKoezryC6z0XKnaFccbb4CIM0Km+6peabSTLfiSx54NWuMKP81tsM04FenSpV lCDbmLe68kkJ8jcJeqxnaiZFRxzh7UXEPLki8qBuALTIwDM8negJL5FTcKvucAqcLuEJy/l1GsZj InzAdKS58+9aZHtaztxlxz/ZPWd2fVW7yBPn6hkyXFLi/gSTKKqU9sIlSDPR18O3U5v5K2Ozswu9 swtz++o8/jJz9SKcA9vjj1/I8g28EjBcC3057VhHOaJ3CPstYMuK3y+YrlqO+4pzKSp9lc/Gm5+P o9wjTQcLxCLXRW+CPBJyy61uagb2ho7zyr9YOtqhklSoExHJi5uTciIFDY7PBAVnPYVu6FdT6agM wR7I9+h1ArE5EH/XUSuUov5tTcR0GK0Mx/Hixz/LKEKPrR35y5w89TteIMnu8aS9ix0NyPSIh9x4 XHB0qhVFvaab5DJkfO5dIKiI5WGocq5efbcmORUtwm7WCGCMHKt6+Xz5JV70PbvtGj+fSyaKzHQf /8+miW3IL5cJNhTZQUo1KNdnOqy43gzPOZ8v56QLLhMsu+FDsQuzmF8q08XPInvFVnrDDr2YXQg6 fsxPzloUAMYzZSInhFzreZezzBMIza5eGBkwBEaYPWkMyu937kDaIoRNPE4Y2627ba4mP6sbC7Ga VULbDZ3SQ338e/ptJI3vw7ekqCrVl/1NU8shqpCJEg2tWEGJZozEDKBmXcAhcVtWjhbxAfSqeRih DFJayOANFIMz/utwQCoMA5TdXYGTVERlWuScEtHVfGzWOsTt6jMEepp2MR4J1i3a/Ly4HaFafMvt 8eCkWMSvb5/pF/seHjU5cieuGpHLLU/lfp5t7cJPG4WGTAfImxv9DSsVKmaGBxiaI3cE5PEz7PwA XVlD2PnttLhbDXyXOUofdbCcpSjNs9cVe+5pyl6sb4nikRmTTnB2TjVprNMXp24EBohFBMlnPuei GmQS/nqyFcjp4cCM7OqX4UIqm17lR081Pb/fiJuR2yhmbyhw1cKZJz2zpybYVBDqkBx+lrtn4nLR PMIwDvWp1HyaiiLeW+eGMuj4fiuXw+JZM2xNaJ0M1Cq2Wp+X29C7w+v94SVEoOKlO0Kkn/izrYRH E/VP5y3GRJ4CE80i/SklYbLLZZmm9yunULaw1J6dRr86LFbYHXJJypxs+Fl/5VnNBm2yb217im/z lr7kDyvfQS26MROrv/5v9FfthjqbWqvaINabN7aprqyyXYErQ6LZ6GEsdSlnM3e6z80ladVpn8f+ bhKTHwknlLJbeQKMb/z+Op8GWugyFmGYsD9gFMGJ7LHDOoA0DflXE8qsNO8L7IDcMj1pJUiOcIBT Vx7AhaPMyp3hpa8WoJihzNkefWomBeWrHmB0AT7KBU8HR8+pQjOVVF709AtDhOx9bcr4Voklo2W9 AVa3+fzlQb4QzY/iQj+ykznf+lFy+50rMerQM+1ELORrnAu3OOISzbUemkgpzbt+JIlNTFWfiJNw rRuCGc+fKO10bKPtwNWz3wKlrhrwXLHaNkFDFVR8lSt/JXKsvH2eJE9pHVO8wu58NL3sjIH83B10 p0dxLwuorkmxoHpGNyW5BbcsRbn0dZyUvzg2cBp++NRcLvPeh4zo9qWGwveK0rludMx3qsKDSkI0 qjc7urHeuyqtAbn2e0DhxTikpDxH/nFCoIBN1PBfJvV7Z64Dpnriv4jAIO3hWjG1mC0gTlAXZ2al MYz2oIlHw1bxYz4R9S+cBmepRazHl2+LJDQ6io3yawovofDdvlnFGrKQvw/Cy4o19KYpoNA1jmKN kgOwvczIs0irPNkEstv8GdYVhWnrWJffsL3kNzzE60lECxyzAV8/nB5f6uikRItSaMLUdqwOrRqt iaVEP5pzlV4rZrK1dGzD37c3hp8xeUE187NSv7O8BEcymA6a1rSZIXdYrYtyLarW16LeQUd0jjBQ DLJuFZ8prT2TZigyU1oDvSHyPUaK32MT0kC69Jp4F0+W2Inb/VGxKBIM4nLYkwSJg3TAYEnpJ+93 JMbVaR8feaHDbfisgYQETxNNEk92i7Apsb7Q9JeiOpZFl2q8m0yuDLMTQfiDrjbglsXcBle4QBcR aULeWUQwB+o0VciYmOjzJkls6zoc9Rbp57LLqZZCIAx9pLW989gMXS3trV+u+VRNpB0E8FF+aaPV /9BO/TR49yHPZoI/vUii6tMHvPWRMWAy7msf77SlC6bl4rci9CfjRBz6O1cLPU3CsjqS9jHFEVGo /bsTbmVIv0i6cWIrfU08bXjkbkmh6Lz5z++4lAMSmx5UVMvPckLRbr8CF3TIIcN44na2MnEXb+TD rmzjjFFwbnB5yIw/azQitWM0vGd9kNTibwa3cjTO2fikX8fkQ2b5NHq8voaGim4fqVt7d5pEHKLu WY+xjxZ2FDkcW+crYAiq15AdrIio1geaz4GgdZZdz5IVu7Nj2WGO1+zvDJfT86vc0DaVDgE5gbAj 22+VL1SZkp+aJoVJIWn6oT4xCWKSwRKMkSf6mxcJXz4bN1PtkeDOcBmapnRxyNOp7Nre66FhjQpH n94uQUdzvAr9wT83pkiNNpv8yUmivBxBdUTypwlLzbZ6g7CM6iogaRPzAGn/N2114sdMVUN8Ml8q 10IWiJEfaHDdmSTqph5CWHgZRVf2uqecu5yqdHu0at9nMKkGw1MgtPeNmEeHidHhbt274TbaiXNG 1GfCG1/vLP4+l7uMgNmhaI9H0YdirSKrgDUJMbaTpeEhBG89+GLDp/VOdxbZ+WkNbzmkwWEypYLB jVbztUxGDP6yS29GwFWdjxf40m//x64fw6slTq8JAPGomlQJ8L/h5eJxZ2bBdkf8tdBfz6dqsd/H geqiD/nsbwHIr48zS9pEo3O+HK1JnaGA6To6CUnV+ekPGd6gwlZ1+8dicgpXoAYv0LygJKo7uSu7 OYiIn6LT/uKvZAln31tEAUBGxuzXOG1XTV+XgyFj1OzRi5GB6UcIDk3DYuuPYP/lnaycFMPsUUCf VrzYd9T76dwymudT7xNYDkHpb5Xs/i4iDE05UcJ5x9QuL2d0r0/eJpeR/tAyFFrQ3nzUCJu/uSXC Ah00MxIDpBlyEQve40lwyh5tmNsgOodRxEZGYb6GC6qbtCl6lgn69JammhCUUWbeCBb+mpBKR4/z SikrvZvLlA71aGbp76vzlSj8ipdlzHvjI6opYcEb9d2XFGqgdY3gxHTHG+Q85uJjshsk2+YjedrT ruayYs5ixa/E7FxXjftu/F2sxu1EAke2WCG/q3fpJ4gbLSNTJK4Jpo//JouuomnnTFqFQr/6ppfR 35nBb+W7ivwiRmClTzcW/yX1qB5HIHsvEJGdK62pajeqY6NFVcIp2K88q1Y5obc2tZR4uGKjMjvy mcLiZUvB352juz3J8jKxHXgIiNUyiwnbFlxSEmT28hnWgF5fvPFVa+JNT3ZuJUhq5YchCP6WPe+D jbpuURAYO9j0bkrmnem9/LkPAaJC7b2036HWxRWWV+Njw9DEdI2P7YgHr8lRlULIHSWl0y8fcBuc O+NkzNYNGg8WDSxlzEhP/rEDMi9U5Hq3BbVWyHi+bWSuKy+72WmUZUwKJmSd1vraut/qkMTEgmTD xIMMPHbzs4cUZ4Nur+oGnWnymq8xbhaxE+AfXDy3HTSolhFCSSekiLglxeF73KHjVW1BlXlu13Xu r8PbdchxvIKfW4+YmOfJx1QOe2cWLBzMCHZqCC9c2s12t2dRhPSADYGb5LzOKA8pm09I84IHNu2C tiScbl/TH0dbWWxtMorJkFIF46+6sxz02DC164QiuReTZWy0HVywE3EeOp1CeD29JhnJ44YEv0bN kdvZpyAuNvXcWto6iDnt5dXyzFJNkEEYosckdquQ5bRDpBBXNH1oaGF/bXFxcBTJ8jvjE7ZDKO2r ylXg6UNqdRd3/87lYYiipzPxWY4iXSo+Ac1E4ORCzvjiKqw/58vJGuMRrH6A8i7DzdnJk9HPae/e 2rmPIrxkWXZxheNaH/SvCftxLt2/dHW4ScSFlz7Jkec4xG1IRD9ZV6dc37YvMWj/gLy6XbhG9k+B TZoIJ7fN1Mk5Mps3ypiOJpumHaEw2B7p5aFYEiZAiUWnCPk5USbXL+gUKH67xO+HoerOaDDL8EH9 0a565LDawTo4NzhpRtrqr+x8+nZ+LEFS7hXgbq7FhHfz8O6waux+xbdTg7hNGp+QistCmN269DTy FHwyq6t1cTXuysyEGPEySLXLdX1+OjwyzxDRnjEfh/lG9Jrn5mgrFRyUNkRy3RmLBnJ2Vz8gse8z XBjRXj4YPGhbzsLSOFt8mzvlgj12OhTlAXo7ABB1K3+frkaQ9q3wRwVHkBsuhHvmmfqn4q8dt3NV 0/sp8sVti5iHQWT3uyEaXFxdAUcPJhdipbTtekLVBsosK8XR1HwGRN5AevRGzvP6ezWs7I8X4lUW JXCSguuhR9CnopEIa3DJuMTHb+boV+2TGYI8I8PDX5OKch27bIBr8LVoggSPVUk5Ik3f0Ts480Mh BgfkHJhW3Xe0obsaPS9F4WlJgM/dGjX84rgjaGImoZzNWt0R657B72ix3hhhLDP01yHaBr8z1IcY GbBcmmku61PZ9SElEZAkpRv0znttw3Azq9Dk0TAu+tW0oSQai427fhq5dyr8Ot73AMUdTyI/jp/y lT03QUwPHTz/2Z+/ddxoalkbvK86NVIcseMtd1xmMTkVPI9yfADlM+rj+wONHxkFKVRSBte0/c5K AhP522wqxjO49A6Qs79pFuRm5KKl6iNcvR+YX+5P/05s9Xv20BCz6eV5NCqr5bHVgq3dJ/ni9VeQ pNLpcgedEnRQ93hkVvMWs1zoJ9cOPD/W1bI14Ials0nQx0t5Dk0hNtdoSi4PCD2Z3w27QEYuCbBt OW9/wKrXRcj2e1W4Jbj5JV3P/kJgrWI4ahe1iQ93K6dJEyhZeL9zPECmCKhZ1vsjLrj/FFp2vmHu 6tmpghoKgCxqbrwwjTzh3fzM6D4uefjcGL9PIS2ryEgG9ew56WwnJ+cZk5+PedhENK1kEMkTu8bg b2utWPiCkREbO04L/EUEw0/7uc4JJt3KMcF9JH63Ex2PNpece2rBB6bVR2nLh44SnvOXd5m6na/S 1DWv07zD+Yu4PSnVt0lNtqVKZU3MqeNSq4BjZZg5fETW6BRyJzUafsLJk7S6AzwGXv4VA3IrRucD lZHJKUL92smA674Qhutgazzlyd9AOlQELCZtOi8+X8mbZB/EQw5Obf0pRg34o1Mbm5ILCc5s6raP H1dRDu/Ps1cjqp7PRfczBAyZKv6XZpECmtdDnpuPUZuU/qZCfxa0OZvNe1gl/1SXFF6Z7uSvD023 Ocjcq5TuX7VFxDflAdDxtlE3qAev4EThbmePF0Vvq/O8iCAZoTo5pfxsaz2iPdHbJqrxRLGZdrmd OnezDSXuk6fe04WCEObNHe6cAn/rftofkkxHmD/kqN5vmqjDcOsXisA72A/qxU06GXWdZ2pfHf8a Wa2a/IDkMk+5UPxFNfME9f66imHeuQzhfjxS9hKwgbawy2q5tbys+aHIhGs0vxpm7OVpKCsqNKA2 /tOnQs/woc646ureSfpNKSqSg1lk/MVgQ+EG3XVOScImRsc9K4qQ1wVFhVPjdnEYIar3soFz36df TZ9Itl9yz9qz1IIWS10zSioklyvrTMHOKnSiMDBL+MGHM99vtlbhOnYNK56dOxZCZ2Xyh731yOU3 sZGb+H1yzzFFN9mQBeOZHWzKw4DH8gr7fXUWQb3EsjJ9L8l9S6NcQ6Sx1LQuPljkyWS+HlvLYUe7 FDVyOnfG0EyLTlkc1MxYeyi7gteYH5aj7d4yMNYXTvWupLAHon4jz51OMvp72u0+7nrImesPVfX0 9Sp4vQ36Npge9r1e/LMIfCF4K5MZxNykkhHdDqx0ugVG8P4zvIB0Pd71GEf1g3bN1Vw+mw+YheHQ gdrHBYdjDieUOWCTdyqB2HjZeoyg2bagZAZvtTlRyLeLxlV2Mavy7M07+xW8uEt277GVqiDBsQw2 Xf375J32x+OyxVW/bQyEUUZ/BdgQ6EDkfll8ZCp6I3gVe/luQkZyzcgbnW1GTegQPASDyHc+SvMc Esk03RN/lG1jm5FI58ZW2iHLIeKTNxbGlXKvGicqHN7W+Z6MAcCeCkTKWp1j8/j06nxHrGfRoTvv 3r4d8mjQJNAneBWr7HM5nps+0o8V/XCPZJu0tx+Z4aVncrbLt5XyKpjDrfBZbhT0Tq6FtrKMZKm7 zRObfY4RuJodqeaOG0ZRR5e6nRByJ8mzQ8bBNjEk7DCaspfszc6Uyd1VYzYSnv7BGy4Yp6OqTjqK rUbGSGuaJYz9UGmIigF+N0GuxxDx+ftU9LkPh3UayEupbHd4dn+pCtetluHhfgtpmY5/t3R10ofO Ueov0+ITuXbEHSSTgCXGCSxEY945tFmJM2Mu9fb6npaBPVZPyXMSs3jOrrXezV1tyS/iCvNd5yAh l3lM+1o9B1b1gmyPZdlD90GP6xv1bhP213lTw1JDsT+xauyqDg9Sawy++euvl3HiLBSTqI1ekgvb 2XxxQFbLV/WR698wJSrs3EI/zTu/l1sDamqXGvAo9FetPdiZ0wr8FPeo2WOTxCUo2heMvNtQeScM CFhvd3tX6XYi8cuXOGPj9AjnyHfW7+LjmPMrToU/f8XUcpKzUA/lVzbcArq0A6n/YPrT04mgqz3w 8Nc2KnBqv7TJsjG/pDQKaVIyGxPmAniWUnHqZlWz1vGJG2ohKVslaWiVyZ5UEx+7htZQltXx2q48 rPxENtekwlt/GD1r2MsFpDmxT8p9db7iyhDd9jT3W0h/yBZYzdYgzfxKMI4MJ42ZiGMCr/zqSKPT lrJQD0+0UAyHQ2PSRIQn39jiZzG7tMyPWF9rbvWDVhZSVnvJUXLyxoEtcb8/DStHap/xvJ1wpS2u YDsdQ94tus0JP8/ZS2tjleGwPQbqk3P2tiD0GLAiAP+n007UGHKj4ARC15J9ykjsaBnd4mpWE01S 5Wbm7mhpCo7TFP/n+TSf7t5yBmtHw/DQqKDjNtqxypMMN20aO9bje9wjOptHIDV3KkXK9H5Q1Og6 Hmcz/d0EcGSQGOiE+4lgFCeboc0pBJBzC6spzkopic8GT2FrUgS9EqqXHN/F/JkLn2eZGfNQcRo1 7Yt7TwalB0nI97LFOoqmwFYvqX2VNB3veGFkNZdnktKIAzLm5ptVsldiXeG5AHyS1hFWMj2h0j3K TKyO47zvSfzcj0lKwtq7emKpYhuzcqVPyJIUi+rj5A36V0VkkoRZQiefDos8fPwp6B1yN21dEXgR o+0j/H1Lf3QCl9OzVHMcV844pHVtnR1hMb3xrRVOCLRnXml6d9gM8M7ft/a5qr6o5GjHjsR/a/Ie fNcsZ6h1dKyOsfZkJD5m3M8L10lONBNwQZGTGm9eoVac7axeYfYdylTJAmRo1+E6INctGSKqqwsu S7kyq8EZnGc5aCHERsVze+vKrXAdsCDYW/AM1V5NKZxRPZTq38NTYBHHYmrUEphQ3WqFkF38RDYc ziXyHsz4NwAJIPbf99I3hqTGl+8lIeRoLfGYwXmVOwoMXRwRZI2jOg7K5p+WtTudxKfZRnWXtWxF vKQ5yCy3mO/1T+zYY9Oz6T5mSF7Px/Ot01RODHQQWcwveWslW6CeaDo3a0j63OFVNoZSWv/Jd0yv Wtw5/tkHUM08Q9efJKuDnVsE3HOQLk3TF9sZTMTK0yd498fom+TQyc2C9XaVPmpuTULiv79yOmOT eu+82Se/1hCgoLzzjo+hH+LBEOT/skaYjVIJH6nmIWcjpaWF3jzFE4G5xT+D8z2fFktZjZ9ePtpj Uwywd+YHiNoQDm2XPRJ1dOjprxgKbSbdDuHcR0tV++lHr77/laVpoWyZAu8WCimRvj8rRCHXY6Lz 4KWDVhe67aVDfGGQU/5RAlprge2Xz1khJyZi19luna6L5IoY1CLbaJuZSy4gAOAMSO/r7MhnxoiV xNQchs7cfPbcMKO080F76KEHHT7JRd6h51pHHEFh88cQPsHpkPUB0GYAqhxT/pZwAbitoDIc03ag L2g+WNhUNHEfUpWuwfSgV2obs8axGFovqqbBbjRKiAlSwax12ZTTP7GqwyGOroHzygm3oTUrFZXz zT08Fy0lBEn+yJodJ24/f898xlptYtBcKN2NQ8L+FNKY+R+MXFVUFN63pocGB6QZakBaSrpzQEpA WlqR7gZp6QYVaUFaQLpTSlpigKEkhxiGGob2+v/97sO9a92H+7Ifztn77O98Z6191lnrO7uyt2yu jMVhVz5iCggxHI76XMl9N/4MB2X+RPSx0KBoKsYHf7KzIyojbP8jiLo+9dJpJd7byXtVsJeAlDFn MpA89kj63XIv/cViUGQR/C2Or1Lq74gSH1lgOv+nFjy81rVJktIE27xtewWb+Zf4wi2fSx1WLZnr CMFIHVvfueMda0we2tHNbuLt3p/XcZCw4iZA+Ys9thm8tdYWa2V+zLfmji7YqTsexOluhT8Cc96c dlboLy61gbSMNEd9XhpR92kfOY6oLEeSPiTfhGlBa5I9noW8wHMJhNM+5IPspFINvOpKjR2SecRC mlpVNPFztgkZHVKe1shSYNZtrOEl6hx3sRGIm0CwiJhI8c3ZETAMxhGjcGkqNGYO5s34po5tybun qfQ7Sy8m8IfH7QHgsXugJ8TqmSPZ0JxkMfYZHM7rBK5ig00sGoCs3bQluFxxNc33a/w4DGJTvPul zkW9lnRkf7WxZujthY04Hkp51FCjG6ymRfvyVHZfz5WO9nVprcBskRPEFYNuibSqx9VbJoXK1xAJ I9dVUSvz48cizyfDfU1MpfEQfRpRAyi46VRfEib3jqhzwxfbEGmeJ8ZGUl6aeVIEm3l5mArE9Dh9 QxljQlIRfc+gbTsYWuU+UjijkgdH5FkExy7gBFud7MyRkmXc0e3W1zVjG2vvvZXxNfYwOn4KZiZm LR5ITPjsEp6VpQ08Um+fty9zBcihaMWn2BhoBSYCKmmvnM4CsAc9tPJz6mkM9O00X6LX0i6SY5hp 8xSi7E41+/S7mwpUwUo7whoPrcXf6pTetERBCjmpLfXL5ya9RowdvhYwpdusmE5lH2B3E9IaKfpI Xzn3BikCmYUkxJTqSpk5kyvegF1VKE5wjBdCVjd/VYbIPxwKVFIN8NHd8SvUizoO7Nbw1juGgnMl EWYAuReoZ8wSw30wEYVJMYnnac1Huh+6SxkJVrpLIdKH0gXOxm6RPyTeWIG8tiRLak3RvdNfthUP GZgJLjlNJibTRpW4TeWSlA5WDEu1eh1H7WbxGoSpsmBu2Z2/N3JtznH9Fj4tekgCFoNBxeO2IGmq z2pY691qo/geMDmdZxsVl1as+V+pwDST275u+cvdF2WPoBexIiNDutfX2W2OIUZ9y15RXFMOnqSB HPps03Hbtjh+AotWVkXMp5xcChz1t96qo/fe4/wZ6N8fxNL7ZqT/Xp2W2dVv0KXTFJgfmZ8GJAeu 4nV7WZhelUv+ytr4ijx8TMabmtvP+tDYfNopKu1t7uE0C7xAfeKhpCW2dFNKTjr2fxN2EtOiHinc AMMSTTX15fMmVCNJuwCRuapfeoqSpxfN0Lr8XpKgCwdbcZBzhZVWsOG+8yr4IHr45XMu3OFQCjQq fWWe8RWBVnyu2Lnu5TIvXztvEVnBX/nqrbDE5dzCdJpBQpPPfIAIgbr7LmeMIi4IYaZl2LDMXzIE fH0qKjEiWdaqsddpJt+8lhb9obd0i8XF8TnaPG1D33Edn8CfErPfd/YakuPoU0CVrK3LRJCR4myJ wOS2OwkY0PT21c8ZCzOaTUc/gmPz2gy7mhFbpjA2Z8t8aVlS3xRnAhpEJDfylT/fSnd0B8lyLbu/ 7iJpNj7JLz3tiFppmlySj3Ir7ppVYDxFh636JlwmScodz/bX0EkLzfnaPevofi8GvyIVC/ktzps+ n4ZoLpZ/jzzknzoOaQxREDdQW6Z+VThYVxnRUfJEdf+mPYZ7x76otvDEn0xewDwDjdgOsOJ7GUkH ddseE3+/DswiC9TiSLLlbMzONZolnd8MCOSTEAWhcJeYG0z3rHrfkwwNyOzt2fPuWqmOqvkN2UuJ hltGgDdw5fXYkyyCSOylrz/3h/i6PuKRBJzjAY+CjaUvBnm+Nuq/Rx+EsGUN7wU6Su0BG4WJpaEA f2BTCuWPpS0UQnN6/havTLDu6IPkyKnzaAmB614W1tMaMsNFUE2adnqhFodIiXD7G+Myjv2N3qAc 0owVhAUYHHI7a+zSxPdiO9IJDMQNahlNG8+XU0trWfjuY0UN8VpuAYI+HnMv4zgRGih9VQ2le5x0 4ez3mo7BBYFR0UWqGvPtKNbL6Ot8AKluv0BBo5uPsCSSgMbhQpMOXNVQwEVMaUwKwZJ6pK5bgBXx jmJcwRFiNHfae+GV+KmeZzq9i2Th0xTpZblZaqajusVYkh4feRxKpmy6BZlqbk3hRJ+qP0whdSAi uY6rrvsnafD39HXQ8oygzbKmhRfOJ7dTyTeM82Qr75R+BRp8Hxg9KWdNNw+oVX9FupvEmXHbV+LO 25d9KN7niPR+JYV7rtq55nFWU3aVjWzJn5O0dFl8efzC14DXJ7eWrZuxegrDzHF6HvR58nBzY1M+ FS3qrNy0Lskt3GqZYnfWmeu6fXV1lMjc+E5jqPSC5nnMD6SEHoC7pVNqE3My66D8YfcD9s5zSfSE ewpg+Lp93yBRwz4z1yZF+Lu4A4pRTono3CzDVNBih0RDSJMFgdlEvgpDUAF15gBHI3zez8uldgyv SE08e3X3DaufrBc7NZG+o4ujDDqKZMbyUKF3IGs8bmZ3aB615RXXB7PezrbueT9mlgNUs4Ex4m9E ONmTjRSOFLKC6A0Vprii29OdPMFXEjeN8YRP06I+q669T7R45WLeO3kNKBNqBKnIp8sYhkVVsyAx IcW1ZHfK0GKZOVs0NSemmRS3Cgv35s5y5Gd35+lIBqsrGd8stYDCvYz0ImT4yX6+ss5yNPRQGXgF D4sLI30AbX6WhcrTK6yPBLjTV8QA9mUDyeIWvouENVqTBqZiExXYjZZeBBR7F7KZgJ+LJr9nYyEy sgdExNpbKxjzdB2wASNaHxqVEYQfU1kLP6eQvya33ScgwAmJNN3upnXZHd1DGGTO+uGjXkknRM0R /pr0kQ7zzTdRszbo9HaZfVkFY5HpmDi/us1fNl07BL3/4iRoHHs8Jn+cxwCD337QMFk+LAI7bqfP LchKYUd/6oSe4FVV69CPPj0NsuaFbownvTz89ErufQvxEflw/luKudJDNRHLrS6OBljTzsglKg+C UkSHtj7ouddzVLq2kfbR+TilWoU8PpqJUzlBZZ/khaC1M2E0PqSlsfq/MrrIV8ooAqy6gyRk+iTy YgtuQDJFlrJSwh7EoWQr6lPlB7/f4AhLDqCI1mYN+36m3dbfdFu0CrKOwhNJObdeF6ZRXTYVVH8F RXa8Y6GfhFImLAoGEzZVh4eErdMlNbLvmaJJl8RAp0dGsi2/9+x3vOhr0gzJ7VUwdBrfQm0gqnub zCYyll6cPweRBZg5Kw3FeAc7/s7xEbiY9X/PWSqnJeMHgvHtWjRsW8kET5oSf2O0SS5945CFkpqN 41sIW/zx0g05RoVppUslsKqf/aVVAsnjgHlHF2J5HRCXKtCOULGSpX5fBoNfD6HjGCRc0axcLw6S 0/0wlMYEx/rKFlbygh+kFTGEq1zZpW0wdXKa6nI0DurN6r9HhPMdiPEBtSsvMfJW3m67Ms+PomDy lLDi75RynKu1TJxae1lnabzHH4lTK/J4oksI1rBt9sSYi+L7rrfldWjiJaUEZCNDMBb2r1DywTCT L9g7nXmHCnooeBrAKrBSyGldYHR1jbadNXaRuPfWdZV0jsQyJCZMJLD5Z9iP4hLsx28YrBWF2h8L XBg88noV3X5BODWg+9Q1g2wuyuPCiUZot30SLo+jgeRdHp9cAtWprQIYOPj5uujTxifrQeXK8BGs dPZPTo5bEqrSmuQnwVplyphcedhCZ5Go7Nixqy6tnY8b4xMr7DXXbxZzZKEC4K7NYQGl88usnArC La+klo2mSzxeCHrmmoFYu31yUg/1NzPRuF7TQkw0DrhArPV9cgrp9kup3STwyXO8Y5MWvpgmLNjC afV0U3DJCnUyCalyaW60+EZk+9d4O+/EBDLXFxw/bvC4JEYC5IVuQSpxrBdlp1nRGzISJ8aqB6Za gWLJzuS1Q7F2Z10Dz60uHNZHiM/05fSg01smZdMxw+bqgNFkvZSViRq/1Mzk45TCdtcY5uw71RhQ /Y2MmJ647yWKZXXcI/47a/1BlTvrS23J4sefUqd8GAM2bbUIi0xT2Zi8TgI5M63JHGdZKl49wQq8 ABXQX3cnssGDlxN6E5NF0iqOheNd9sUoBkUL3W5mTw4j0eRqRqvPWXs3g0seHZcEZUI+WDFZ+T1B yaoS4gehSMHPBdy0TCOznOR3g0s26pKn9Ta/4QfKexbcanJezfiwsqcODaJ9XEut1nqtGX3kME0m uRSEAl150wc94h+Z1sPiIFhujtuw4ElPejPpuurbbzzMOnjphcDjxZdLVbq6lIDmGDmSL22mirYA j7UpLFRnnrCY75zQSYN83URa9fcnQ5t0cQyX0o61o7SePR5gbqS5KLgPypfGm58hFMEDEKM4iTdS pQmnYkCrAYPRngyQqbO0TXdoTVCMSFuT7GZz23CKnce4NcMy+7SNrUayxovq9zb37bJltXTtWoK/ Y29Js6/sIpEvphc2hj7pFMCnQWEVgT/w6uVyddyUHCNN17bMfUG0dKNaZ5/E07laD6+7NXeqtL6x pQTr0+VGESOfrfs/55eILsRSJ+Qtim70K2CchNStU8nybMoYLw89SvTA1b0QnXO40BDdCqx0q94q Wmjd6tpa3h7as2KfGDEKUtHHcWHVcYsq3l+kMDrfNGcAVxVIxIviGD5hj+HCdvWS9xSIrnil2K8A pjVsoiDYOXFwDTXN9Bp+Ukklxw4GTx5PscS9iRmAPyIdqetrYeEAxuRVJUTZSEqCRqaSYzAC7NTe FbLxda9zlizgOGmQuE8J5Tkeia26leC+OFEPIqkactmpcKVWW71uNCqkeFIp0foHm0EIF6k+Aa8u juutdAKDnUGMZNkK+cLKkHdnieSydH1iWxcObcRnOmXEZs9RcOUi3BRpzbndy2ovsMIgmaw7hkBp yJZU1nGxTnD3jMtiRVXGehhF1hTDuoR6BCpcihaOTZMOciqGnMAZlitSqrXBVV52HOUy+erCJCeD c6z5vTkyzQkl6EozCF6Km04UjzSebzrOZ5vyotSDz6weoFPlhYBCrpGti7dHIiczzE35qThNN1zT ySzfQgYEPebycHLeNr0I6YMMLMvPKvPRyyVBIp6xR/4ttxxfdiatFYF2jrng8GPcON+SqCkyXNpT SMQNdFbzobHAxbObkX1DqTTSVnEWq32TjsAcJrzG8UayVdBKD2CP6T3HN+LwlbAgJUZDadI3tzwU 8WH1B7Q0uMkeDp2kGkosg2Qi1rLrLZPPWQhsMoWZLn2aBYCOCfCgq/LChmR8CI5lGqZxmXik3LdS 4/jnQMlRdq3envy+I7wmsrD7CsUSnS02ouT2qZLoQEpM9ZPXv2mFlOo8n3yOTIlRzJ/02nCw4wms rbirlbQbqvM6/DAlnDZWocN2cJg7S9tcvMfBwvJ5Syeya99rNdWsRvYm8YctLo5lfdAdjiWW8wnD hxdOJ2APxpQSL5BsDUcBBJr2pvL1zY2VEW7ZI8m2YmevmhdUD/mUBtpf6pDwu8jriwBhSxfPMkb6 XFg56EGTZiDAQZiW3+KWVn2vuo72V9U6HBJBF927lwetlQwRXQgpzZ5zHdbdrTGlkktiHPpWK7qO 8KL0HtL2Xg/gCF0ptoV8GJpS1OFTXgfIPKZ8dYs+GX2F9bBL+xAM+tje3L5uJSF+oJCzdr+RfbDx bsojO71/A1l0kV3bL59daSVdh30//qjF63Jc2tCprtSAjlD7ZBEj1bG2DIthmJ3S231CzIuvtXtX wy/YW3WzczI7YdIpesLc+xjAFt5d24Xn4a5KqaLNouNIvwkD/S6s3jTPWntfP9y97E7HWPu5Yoli hYbI8vDivCHVi/oizO15+8uG6R9oWLra8NGb7m9/nyvpEtN1PEydZxLG11+i0Vbsm/s8LfUKEaIO 7nauXJzSFVJpU1nplm95hkXxryBEdfW2ijRXGN8fRBZN2z2JcDU7k8f1PjTB+InUPY+jsTZS+vwh kyjhllSi3xCB9Bk+ytzqXillxXmVPOyDb1OVSsxEKclzT4MPp5ASwDXOtmNkXPecYq+PL8e5omja cClnUae4Xv2JtTj0FDKtvtwiSZbn6DnXd+AhT+mmS/GGpWIJyQue0dbULD/Axp9t2GIhQvnKJNj1 xV/ScRM9ckCHplZPFuEy40nOBxQPlUEnC7V6YxUVBcM3HJQnzbHkDzuoOd7ULW/s9SXHvNgc6Y8I QaRJZXpemldFIyFBruvp6mi9vNgoGwZJvZ+heIEAHsm3kdHbTeGFwzpVTrLxsW0IsiOK7T+6huCk bjUpId87Gcad2hAt9VO/def98jLE+YJ1gpakW0l2u0ubu5NUAZb65c+PkAj/LaytWUHkV50+aFVq 4iShWayNlG/HhUHuWQD91WaNaSSRso19P/kPeN5tk3wdYaPcNXM4FdvZo2oy4xfuxQNXF+O3uCu/ JOCQG3n9E9TQxtAGkZgrG5+7wqqTEtDfxVxw7smve9VnRRtrpd2vC1+5p2GvPtfyQjdQeY7ltWi3 HRRqINU3H9HHqlCKL5wye9x9Fj1ydvMifNIWZXsQlMn9wULMBpOJRIT3bsaKqZfJh9jTBHP8bqgQ rxpKU0hi3JUc88z9oa8+Hfeo3XFCQUtT1i/W3g0p8XjHe90ZV98nJORhPPVmEkLVwszV/EhAtmgV ryndqBu+bcFZQAcOMR3Wf6zs90qPtIbL8NMnEEKp/sq89iXuo/V1bBU9PikNjg0Bf3p+18EqTtC8 v6Fweh/CQrZZGxjdXVZa/+VYDELxFfkCLF7+IOLIciPL3LMmY0c6Cl/JOmc5RVvN+SeFZz29kfhj xR6zeoirOy41DWWo/tXEDuzWKfLqBYTeT0Z4mwWgOH9ypF3X6GD7eLhefdaXK1dJtDs1Jj0oPHOW Btd97QQgDt4R4KpFlN8RXi8t9UPSoXcy6rlPm4G8fmTEo9vZb3EyuKecjTEVGJdk1TsJgZlGsnHV DbPhGt/Co7xBHw36PhIbbqLylusgEU+dvmUOeP4IGGz3+UFLkM27JnZgCeh6b6TvSO+Z0dlOODgY P7+XdEZ+rPWN0vQEzp7OsR/Sfhm2xl/0sLJhGlAea3vo//6NO0hwqA9O+3Ao78IMDbazx5XyiGLb CmHr+MHXkXUDyR+u16v45XRzKvF1w0mR/KtGCqBW2UHmpl5bom0qys57helvhW1//G0LJASUrSw6 9KoEIv2oLOtJXbXOshnmX9lvEnWrfc+SibFlz90GnRHi0FSTZbFi3zefNGm2kFGxMtRspbWqtQFH 0QwO4G1deCI/pcjf+lDshlVdBnk3jWf8U2dBg+Rx0yj0mQpdXIKUuIkxv87D/seCp+iYnMMBo9Cu jk4Yg1xIT+h1rY9faLCX3/X57iVisLEtqKdnqfP6Q4/4RP/qzu29ztbEfcLd/eWAa8991/bq1i31 b2pLaQJSvxwYzKenLfDRkWywf7r5OgNoFxFzHunWs3ok1y17LU3r9zHoHhV4+/vPw2VjFeLeo+MP +v749Pd+RQE6J6YWWXt9vRMdnIy8DhBDD7u5Hlu8k5PuDkX/OnjX8Afl92X49rDnT6eczMkYlOAm +NpfGHEMEh3uvrdWs+pQfbg+u3IIapHRgonl3Ka4ycpprV4+JIR2d2xYwiZ+izO4iro9fTicpZ71 K1N7193ZvtrTIfns1vf8xN3LFfVge325ebm7VWYb4Oi7bQnNudfZC+38YywzVtmQGJpntxfqXKMt 3Gsp92d4nyz/IaMn8CEFun7wcf0Auv5rzG0f1bK707KLark7M5O9v9yHxiAeLncfylqoe+739tFk HTDY6h4CtW6xE3qz7wD8R1xjuW65KmvhtiQG7agagKKRyTlbv6XVYnRyYvhgtuf+QXYFx/xTcnWX e0xrd8Ft9ztXlzZBIV6d/l7+/y2RiYCPXBsGPRzCJmo7hreYHi4vSmaZ5O5+Q8WgOWzPvbu/9dwp 2fr27pUZ9VzunO+gLg/eh9wfQzvQHWaqIbL8oQF0UMTE7yvX27olt+SO+4SjP7looM4yKIX36nfV n/90Cfk/FFtrwMhvSVgYGGvM/zZ6+Eex5ffaRv9/iLaOTLVScgTIu4wOQmODkZtkzkdvM7K+zOcH OrbIhYVlMGOqNot5o6F+ogWpiMrf5FmROizCzbR3/udDomiynirP+vmFx6X5LJ4xM8rQ7NGEQBml nvyCbnURD9lv540iTflFRojpgbvDj7e+ywc7OgiZRm8Kmq+++lJK9MgcB8o25+KqudVsVeiGGa3Z V9DDso+dYRXrbApHUIU3gi3+e2w1vz7Zo1atGXFvmm9dbxoXFju/c8xOKjC/bGOq1Uigm2AZ6lxs H0CW5FFdE3sMZmlkrrR95AgN4W3eWC5ll5aNX6M3qrivMXp4O/jkMMWm6zrhekmECcafiC5tr1MS T1jpXh8ouJ0T+I5P195CG7Efk8AxYVXpB83mItF0utmckE2sp1iqyx+zUB64WT7OINunQwgsylw8 1KfgWWvgjyszbNCcAVeISfMFJnGGoQMKhadpz2TeeTMyvveeCEnOlQ5nh8k+L++N0GfB5o1RlgFj N82afY8mrMRhEezJ5ytw33E+FthxPjrftiLjbbMiGIgXiIup25Ye7JrzEQWIy9aqPLAgEtkJErI0 saSGmBHMzDhEfYBeD6AdZ2zQHVxSknj/8y3X4TaB+iGrAyYvsW1pRGOKxvJO0OaXxNjDDOg+I5lz m8kgLi3xAjLRncp9yc0ksRjIoSw0ap0FvBKqFMFr/UEYeQIIoKXmz0ynIaK92GlVkEyXVrUmUCf4 KAIfK79g3/2ky7sY5nKrm5JHRuLahK0KfPyc/zXQMGvrF3X2j+8beuWpw6pZw5TDxE+kCXzOWq++ UFJgJOLfnK17LLnxILURKZasDAk/UMBmO/hD64xId3m82L3dUf/nBQeistTplvOX/Xf/91+TvT+a 76voMDDiz/7ts/Ov4NA7wPnfDw1HryZSVsR9ewAjf3TL9T1PWqtuYIv5Kn4wC/rDfQTi7AgEOOBu em6bZZBWuXKZi739CQMzncETP4IhY5Tro51YqJav0K3l9ump0h3laHq7fcSMdekr1q/ovmGm0WH0 SMH93RY3UwikSpInoeF0u6HrlJNvd4eVZy0vqSf49mx01N/ALd0mbft1Wn6S3FfU1V7Bn/2Cu6MH k67rzDIUvqzu3FRlw6lng4lc0E1j/tPZl3qhhjWzWD+PfzpmOW/Yo44dAvw+Tszu7QR3aCRMzO6v rc3Mck9kkJDXflxqBzXUrsYEI7qrqQ4rc8t8SFZqPG+6XqY/3poK71KRCM1fY4cF62cUzPsMvqu3 vNp7beJ8MHPfUJJvv7R05dKMFVfz63ZGq00jXjCzRL1LorZh21l6zLCBT9Ysn7qp67JTVO4sU/dn xiZjMEIpvSBpdnP0ozAKts5bYG6RptayhNWda6DzZs/W/5RLaPKPBlZ1tHjjBw4+OKWIdDEfTjsE uZZ5jt63aQ6PaBBsFJK9O0P5ZGW9bL72FpWVeU1mv88dlMVHxSWIb/Hd+E3CRctY41W9NvXEuWXP j93XlrkfYTZeovkgRluibdTm4HBAO8cE0UW8HW5J7QiRxLUz34zC+2aTAZKQwheDMaF96tqxEfIN otxjIiwc0ooPTJHTF9/By2hgv++Kr+Fqn+0jyWBeRbUUFfjVd3xM8aCbFzpDYQUOCDVGApefEohq IfyjgmZvjzO8y/Zysbpb5a7we+YDEhF4udi0UPGaPEVCILYL+wHJcgmQs6UZEL7SyIrHRbHk5NAX EKEUCX0vlYzr1qCVHxinKalnbXsOl6xI93tZb5E8sqJopAb79Ay25tpvPPjCxS+qwKWy3n9vfiTz siYPkE5dhRKqEP40FyDguPwCBZUYv1Z1m0153w6rRrp45pQVWxos9Y9tFGGvrJyTWTnk848xBCoP fCpSR98a7bxt1t4ViD4Vgs7QrNkhP+TMOMedsz/9zqam38ZetB6aMb8o/k1pJE2Jcn04cvlkxHri OCU0jb8eEV/FYcUdoAz4GPtmAcKcgOCWZNay8w2ppSzBVFQutDXqxL+6x3jYh1D/Cfk1xHI36+Ex jASc6KjNMPYgCzqYVNgmzksC5QgPLIZnQtD142MHrjnnshvRMVtwEC8kKo58NW4QHSm/Kd4O4DmR kCyYsl4AASD+32K0KZtxmdl4i5MF3y00qGuIHgOuctIdabGC412ZkxZEIgzFqpOYKUnaxfZjEv2P bADYyg6CSijfvZAYPCt8wrP+u0Az1zthZAX2uWJFJ38v9GVZsYDjbXI+tUbSEgUjknW5FdZLrVAO w6f5a3RpFEasmY4lUmgoBuK8mRjY3qoM1NMMTh9FpF2L02XjFrWyFJZ5CFs97MC7XM0EhicwuGdI 7JJzMA2+mKnRj/1opZWvavEQDvtgO+fekpZYIaiokpIjxCJIgZ9aznRCyjxH5g8gPwB0YuP7ANzk 0h56pcIMRUTxNbP6pMLIDeNMDogUhf56xA/hxfuO2/8YlrnT6Dj/AjghLQSuynP4A3TjXBmp/QHT /dyCHwpngLrU8lX/e1kU9hpm1A0mEkNxtQ+mUyL3N/JxEgmW/uu/XpQkZBGpxH/n6zSIRY376IPu IyP9MLLgeEJ/s2t4H74N4+aowGz8Qg8pZv8LjMowThBPlShJSrX8Xa+U/Je/JkxXboNR/t+dMHbe K99gIzFMZxaZBV7i/c04c8KMP/p3npOOvnojKe+0759lsbP/DrG3+4jIPxanludpDxcxxerEflvU 5f2fGOPXRoqCwP+gBv6/oH/53ke4tqgGYujELlcWSyVY+4d5bAPMtf8GXsgfZvgfkPgkDcJ/Senn liLvt6Cc1bwP8wtT/mswio43EE9+Mf0l8S/L4RX/0P0eoAD5ZweL8l+8WCxExMt9NgUipsWxQfPk mu4Hb0t0IzR7cy74vzHj8qLUYrzBI+yJhXCBFN1HT3+e3XPyMgSvWzP3ldTDpHkE/4uNtwqKg2GC RXEI7u4W3N3dHRZ3Dw7BIbi7S7DgBJfgHtxlkcVdFrfA4uf7677cU3Veemqmu/pl5q2rBvMNRw48 bvEwxip56xrsJegv25Kd8DRftjROooCZ/r1XQQr3+Ai6KE/dcbzd8N7X8453HJbmiztLMApzX5QT W1a6rCm9oqEG1v0SyGqz3UbndiclQK7aJc1ouja8/y1RpHcDU+gc+24X/bFSR00vMr00/BE5HQxO rRy9fSjrHfWE4Zwab4tPBO/9jl547/0dDXwPl8aofP36lVxN0oxcDSMJQzSfXE1NJJ+cXPU/uCTz FRAVErh18/cU+g96gnf3HiAQ0BB4wnNuiDEnJxoIFI1J+9aaDBwSxaisrHwdZ/SU22Z0IO7F+EHV uVGWQiYML7erV5jKYggem+GLRgSPWfcVO1mPhC2FF9J2YQZm/xMct6QzaVi802Wfcs6UrIa2rsem Vp09k4Xp7L4e585qqV6mfa6+o9GReUdbkofbtTUL/q7YbJ1px1LaWiwLNNxD0VpkkkpAzIBD5QTl md9Vocqo8n2988mTQD9rUFD6Da0NTxsKKjTaPf/xs77hl1BQM6i+ynaPoiH243YKdEGZyMDaTrIY 4ip22INsSOBKAemOH9CuHJjmotDaZXGNsFhTbBIaWO1A1//bbF06PDpbg5oW9O3cZAXCbxWMt/H3 CrVISnhHs+BVzeuKG518Psjaq3klHvC1D79OTTaRNLGr6nbgt1xUVLJNZu2y5XJMA5FDzw+GGmHP 6vMb97qkVrXaLoGV37BoetmtLY8WNvJqrU1Nn021Ca1ates3rRzMB+9dypVliMygUbm2Cl8Wr6aV WAABP9GfZrLb9+FvXE5cEH0hc6bkZeg+2xzUS4ubjni/fCHAEBeYQpm3ls4SMBQdjBcx7KSXp8gg bWp+/ZPdQlQkmkgwF0c4a4gl0+hwwpy6vU/A+zDgYIl+gjvHMobo/hQ7xuGz1Erq4Cn6aXMLGh+P J3xr8MZIa7srhsICT+mP4txJur7AC/yzLmgBqNI0esxnF/+58cbLprNbRW4M0nAd2reSEofHYweK fFL/ngdo1IdmlTIZnM0vfmE52TVbr3SZmqkw7txp4AgnEnd9haoC2EZ90Ep1/EOzDcjTZXleL76v SevgS/xAiN2AkLa2dlds9TB+kNqA4fjqSBiF06Fzv4FfartvW5nf4J0PkO0LK79441XKy9dZfAdX 8daKkdXFzfwu1W3y9/rDxNeeZDhytrpQDSIVNsTLs5Ovs/S6tAc49ZG1xi13lgKa/HyWmHSfknRH jnf+JxJxwKuJlq+x/H5bBagVI//PaeJ/Tn7/OfEn60Y++83P0HQhWb8t7sG9IgWOPAhQyWDZDzGl ix6DafSH86ui+mN+yDwieN3x9rBQEQBlYoRfQFGYw2SwruapfFy7pJG+hbcaLaPwD32Bd1MkdwgK bUARhJ6ditfoQjRrK81HjW5j8Qlv7e2ykP3djkHXnKrpuVYit/kv77qI7evCteQurZMh4TC8GaHL Z2e6gKfSMclQd0qi3dE1X02+AMn0XtEum91Ikapfsx/xd11MU90uvyy79MG3FrBV+hV+Q4eT28p1 RnYO7GT0et7LBk/zOsu3qjw2Hss4VZvi6SeaTql3HApWV2KYZWs/Tixy+vS9TwBTRFnuj2p2WxV6 ALutSr2aN5ksd4wwns21BRhejD9xXD7XSKiXfd/tBlLaqEmz1IYWFb3x0EFWY4djeUcqOQSZVhhv ichq0HoJnZWqEtZP7xfQMhdynCrmF/5EEsP12WOwWFfIp1DUthGI0KlbpcIImE0kI1DU3r2olJar UzRhSBuxl/+xmzj/sVaF/zd7EIrUPo1OaYmAjo25JmrvBoXVrXlToSXyXK3tDlJrq3G5GfPoFYkR z8ozQcTklHb6EnNBbiocguTqjkblJJhtmEnFN0dcIRiCxP87GhoL/7qTOcb40A3v67ZuefS55Zde 9kmCHMudIM4SpK8i5frbn4Wk88Y6S+iHYelFPD0IPu4S9Qzyt7KdEGsCRGRyqZ8KI3PtvMPJc+Mm Vf77rzNTU3rpX2W/9F2VRFS50oQQMyWYqsqpy8kKUuc+30TrtLSif2Yx+MDTrufNqrCOcJYHG/yw RP4wghk9kNHmcraRtuasrziNE23W0IIMtRTmhWi//zVd58g5QPy5wQiXCTeJj8nsyPsNm00ZWZ7E YyN/BvUwRaeu3GCpNsN0BvcXbbPbmug0cywLNcaubBPlBa+8wylm+iJyqRLpvQVOGF17FRGH/gIb tjFlr+Bciw/11zwQ+kTGFTZK4ER99JLs7qrcOmF26zWXljKbAKiH7p0kyQ2a2Fy+BHIuSGEwLqrO I/DzScOiQsSuuV/3iB7somuRjbFZ/88bzSdyrsYpcYVibWw9VV9BL/27oa5bQy5eUp4DjeacLXLI mCpgHWCQEmavBpFPv2ho53PVg5BwkUZNHqdOxDOqIIT9dv0VvmDsHy0jIgjAvXeCtasNu5zG91rc gptbSP5XTe/Pl7y9N0Gpoux0yeLjV0FqRUx7ZxAm5AYSANZc9rOdqbYWpOctOtZEMuAFOrhRFZH1 uDKO+42S0F3XboEUYTbxKubLUWo4fBlyqvbS6Uf3/VxYWyCmifeBvW1K0oUb1kiFmFzQqxPdDyVK 6U8EYBODBWO8he97FNg6tyJriNj3mbnh0i+USMjpe6bWeB4TJzagJIpc+5JtcW67+Mlnmt4BXoWX SRUiTKEB44NXu3U4wbbeOiHzIhdnlzz0m16F7wQtcn1h3LL0dB0R4TUrznxs4Q1RbGws9MpaObIL 4SlIHC0UD5S0++g0GV1xllEW/CWQ8CYamVRfPO4B26i5ufW0k7AHIiTC8A45o97pav/7Lv0BkSWJ cjmdWl7LZSe08bzCtnoTly7rbhq4iQzYpIawqUW6TtjufKqw7Ff8Ph8eER3ozOjCxlZ19ehzBxct xz9e1J2CpKJx/DEsrxgLLM6WGtukMBcgriAFjXQBfwcBJiUSQw6LV4RE3W/k8Ips9830dqSnQOeP TQSCj9GZpYNzIeiRe7j65OW1oWix7TDbgaaOf/sTTBN3RB2CaTNtXIKlR6UVYcnK5Wbdne4d/rrn Nlp2xx6S+YSONNePF+MuWMe/J29QttQq/DQDFe49CgrZ8QGGeZsVtYEZjch89e+2PnqDg+WreL+Q 8rk8ApVOCJVvngoXiUa1xOywHFjt3CRobhGB+69MBkWJ7neSyHPxz80RuLpcdF/v05NPN4VIuBsw RJ6HC+eHFE9PGfM+HmQOu5tjMYG/9Y3p/4lMQSZ8M+xZP3XRu6EPQN/aBlqD08NG8OXMsCcb7P3K roRj4Vwyj/MVI77cyQjZpUlHy7sFXPsaHPv5FbGZDlJ14E3zqpqlGQzR93b3MxToQT32TCtbRubo BjSPAQv3OMg+UszZ8o9hh98SHbIvlzfYt/Pnapoh1i76KVwdqan43pjjiXJxNBLT4JSv8gSVIpcr vbmxI1SpRs7ZuTYykh+NZeF/I+AfRh06OaIJJ5kYweEAsvjDdHMSmcXCl6SEy15mnNxiEltZuU0r hKhipbI7MVygHskH17unEX0mGF66QvYbBcsnaH0RDWcV79a1Lm1mdJ9cZoSB12ky9QT22J0t6WCa MEPksEq6o4iuhne3W8xZdlA/V7UMFFrR8HjFhdQbOfivD0ah7mJf6UicPpXC+1iS+IX/S76PyuxF i2Eow6U0Y69E5ve0JZWil11ALungpv31kbJQ0j8BQWryaubNQI4MdeMk2kDY2cdzrsBRtcTaEzi+ aDgHU2ui9T+M9EYK41Oo+/BUNLykw/DAyRZ3+QakvUnPt13vmfoPs9wNqzaW81Qj4PfwzauzutTO yCHaAL363Kzki5f7u/eKgdKulz+R0qUYVN0dDU4XwcMGbCw9AatXI3xz2kCyJJEWLpKEiQTEqIO4 XhKbUrkNV8RfA2zdKOYa3mQ/UvERIGbCikNzDrbN3tmjC3q5PB9sG4o/XYSHLAuUnWK5Lk4nVYiD k69oE9uY13udSUULFA+ubwrKFvZruxS+G+Dn1YJ+crPDQWuehUMLbxK7063crJOPms9Wln7e70PB nVIjEdVLav7giS49R5F8K+iPpxRIe6KNLd1AUXwj60+nJbNqVWTfrRXqEmFHFzgpTae1frsG0es9 +ol5e+m2GcnbSZPLBSlZ8OfvkcvJTBaWBgP/FgS0hweQ0wNJnpLUZjp2WpWFO06g2Xrdr0/HE15N upvCA3QQoL65bgoLsR9si5tudNf/N5HzueoPeRcHaVidKJ3XY+nGZVMI4Z/eyWyxDbxYaqZiuN78 hd6MsHhlbVSq7xckAdZIrm1TGAiVqoc5v1PpN54jefvrGQMagRs5ybAslzdcRKW5p/+0Ns3aCl1P 44zwsZE2bfzY4je7zpYR1ZsWigMowWRmN37ey/mQrSk1eufXnYr20bSMrIQP1MmPzbPVb5wkY+gV hbqLSDaMVPvgZPDA8Vrnn+5xxvaGy1QTFV3dro1d+nbvMcZtvMOfKVdOKDRUNvv02hSVZAe8FyRB q1B8uJhoeVQkr+IhzG5ZhxuqllujaXHk+gbeLY4lup7mLkqBCWucBm38QVA9waoWrotrCN5tMyl0 j6DRogCzEewbD+X+ecbghM3S/EHAQtRMLAxJHpfcREJnif1zeVtbBIJRIEfR23vKIMPjRVLjdJJu wablQE+HbuZWB3ENtVj3tbTsLmmmCvhj7fUPdqf72+i+LU2aWQZLdP+83by6JULqY09C9pqwEYj4 i6OdrNiUdbUmttCyCu2QbIk93rCkOnEo4Rsiau1D21f4jPURe2M3OQKakt2z5Je6nhZoRfJm16Wf KsszZOts2BP8HHra1DsDfRlndDshP4jpPxaF9O7Z1m8i2O01wnt5mBdCO+lxhBrZx/0XoF89/6BD mqvMyHKYhYthX5vrCcga1eXPoXbuk4+xtl5Lpu/+GKYbXda9G7E97QHGvpX/bQXBdChQ/mlkqX3e q3Wq1MZIgOD+fJVZqVPVKRuPvkNFeQQDbToNJf/GjMfz4ubjpogl4SwVcg/nDbpMLvZY/z5tGR9U 40FKn1ynTJO4ZXwN7ajghsHpbdDumDUpUlDuWaqNmwmxcW80brMs1cj7zk2TZkfRXf3PT3AH2/GZ mvOe3G8tBnc9IuWkhTjeaT7zDZd6CHRWSRlK7cDR2m2C2+JK9D0bh3skVaQldt9UksPmPAmT1Tyt U/pPpT8hnTun9QhCvarSdZpzn0WtRhSofJkijbomWwNHVEagJcz36eER0BYiwnHZuXQAgqp8EPhw KpgNtgriW7Q15Pnxxaco7TNhe944xmG5ayfkqkXWT92buZpr1fqafa73CFU4qFPaKHOPXvn8C2BI NWvTHP5hbybFrQPmfHkWh/ildwL7RfCaOSuThEPR8nj478+3jrU0q4xxb/HLtmaf6NttCO0ARR/t cgiq9A9E67MP7V+bpHfcU7otzqHuLifwE6lNS7qB0+v+eVxMe1RDfgcvk65Z6mwNhP2Fz5lcvE6h 4shWp6mNAZH2kQ2No3p/4pwx0/Y0CjHG53Lj/MKFVBkgKcl81nmFzTSbBdYQeFxWs72xqXYAUf1t q9SpGzCfTMqn91uS0ytWjCSpmJgNkGaiIxM5fYIRFssucQjHs5Shoi7o4CGioXCPhteANcMtZYXs sM7ENV6wE8ek8ARrfKRs5IQ9n07Pf2LfUeDtKso4Bd1IztACFrIZPFkSm/upkz998wn/+c8C2l0n 96EZOg5a3IGftfBtv8Rsul/xxFuPHzcQ7/jKVmN73/6InmatSCibUKPQmwLAPEQ3Qgqv0/sm4/Ks DQWJlvLD8a18kFj5CGk/8pXaMioupQch3uvrK5E2oQd2oyTZlgUwWFShlP00+Kj3GWtX6WtIZ2p6 If+AmH3evLd/3m21f96+77x9YHw+Pn3ev/aTpXadpv2qiTytzR8k0YwFA92gQ8iso41kLvz32mNQ t5GIMGl6sIpdrn0ALxNuw/vSeXODR5Ao27+sGHNsfSD8ztn06T6TKDqLPBsnOZGBC6iW4y7Dgil0 jtdTjnOvGz6xTdvRsUKqBwZora6hlTas2fbUbgF3aYvvnapXwGmoWQJfUsJOPfO/c34qd6hqYg2d H6y8f2LLUaygLYEAOf5HDcnDzctmBY8jxAuE8P44crzzm9p4Bifp6wFrxzK++MSTZh62z9F0F2dC z+YQyYdDySITikv1p4nRmL4ise6Pi1NuXVuSfuudjjE7MVTmoUYuVOZTTMDYIpJPF09AsISZFz9F rE9+M0TEMASotQGmAnNpRF7xadWKRPyAJ9BNa4ZmprKyA/kfwnav72EkQ4xHO1s4nETXAfzm5Yez zvRvwr7pFDjMM6/g5567m4hIAfvvjxamuRIvVcgkQCoVKyQglP7wTSxivCbJceauUYfStTz/ERPj qUw9im6UkIRttvxX+QBtFB3Tv9j5+Hu1aYJUCeEfpwYUtJmhGAUPTkS8nZL5/AfuZBHNvZvtMn5D 3BtwoMsYdwHdP75XRd4Z/MDCpovdOc2DIIKgufeN7nWc2SZCecIJ+UYQN0ZVdppXBWT6Ghml1c7j z2k5axY5Rvb7gfjn0dPOx5PP50O3+NtVw5bwmotwsqiCHgbtvJBMi1OfAp/bfiluf83ykjbVvD6q frhEHbtd2fljpXoN2+eT+Od7d/9rzfXHrZnPQjEsc8KEWwyCt2fs6zLOmWrHX19pgY1BmYUaDxlL rCbUvCkecoQWj31vgJ0q5v72LXh78Dt+6gm6iS61txOnsxK8t7CF8nw5q4vBcwSvk8FvCy+yKl6n FovyKF4ZqTqL7i3jukG2Em/lqWQj+9/ugeNq3plZr8h4jvVRhkPHXBoO+qIIDmjusqXxGOd1x5P8 tZxODokHVtwOJr/duba43wcc0IySorSGhN4BjqRXfjAJrFRYHhXw50jb0GpDuUk5LDPb+aVkZQlQ oCGWhuLlsE1KqKgvS0WfRf/vWJZCPKL0BAcKamH8//dDzcXL2dLG45uL3f8XbRkkHYznBlGYX2lg Uv46KWbujMnIcGsrXgpjK90Enp6FomEcSzJycscuImhNej4vZN9iBbKYDQbDEcBbJZtzxCf+Ruha nlB9WYXs70C6dz69+gOe0qz9/EU20d6etndNPECk7eA9sMuNeH99XxHq9tHJP4vubTKMia1d5TSM oM+h4I+xa1PX/9YsnTYYeb1LFP32CK8mXjRXuZGXF3iff7H6/HrAKDgwMWbVZla0N3cBtu2fFTNT 23FNegW+5IuVdT+8HdHf9PhqiB378ndYR2/cYe1cA1W9p5OT7TynLm9vObdoj+S95Cvue0cK4g+O m9XR7d4S+Q2aw3fcRA7nwIwNhW3tP4hTIMaih7Jyw1NBeiZP/ovPbc5tQfBi1z4jc0Githva3pu0 fujyBCMTL7F9X1+v0kJPsf6RCYkXPxcss681AKXfCcvIM94c93oR97Zwd36Ek3vRwfnewjIAX6jE 7c5nniunPkwOGjA2ukOj2QUPwfizvbU+PuF4H3YiFJu/8p6ytwTfc3pou83689POiIfzTcIwCLIL nipNvDz4Em0PwCwMsxem87G4YtXssAVzs8sjQe54DG8OZhSb9Hme/dt4lWpFs2be//g/Ix5+PO01 wqvW9O+uHjb865X+/PHjDSPvzNF7wsrvGXyCuuCFUJ9RtMx7Q4Jw81lphb4idCvykJN3ngmGbkIS rRJBCxZtwFAfiOuWJNTLPjgZcpbg6CvY7dMi7FMgjA+jRbFIuH73vZAt/fn1poYM5UB9Qvr9AZ2W kxhQW2e9kgIndGmKHaqArRygWJvV4sdxJYcdDBfdGqQUpLKyQXuuRbwtw4Tmud7LI5XKo7uyqD8j Z4o5zckJ0jdZHxnjkd/Gz7qpkjZIgM1lmDd4SiP8QqtpH7nssRcwNYH9USdowxIbPeWSrXPV22RI KTmdHP3dv4PW4h2+LP1ldefTgOLTYWrk3Fm3VmkNOcgJHVX/JI+nlyTwpTlYAKYkNNMWwZHHzxy2 ZqnS8xMMwwCtVomon9U2cUC84iiDWSsByc1i1qRN+95palQrE8pfEDnIVb+2lZrf0FEKK9hulPDy 9USf9iQtHt8jSXfK78+DcPuJYbIQ5vduQH2wJXn8sLGQLAon+9cWiNjVrPOOVeWsmfiWwKXuud2n tQjWRMcfGRSiOfrtQJFEo5xm668+8Ip6Cio/m/MSN72sRjdEf7XY//PsTsyLo+VkDcyKpBUJFjOC L/XQdmmpzAov+7sOCXOzcq6DWxB3vF8biCV4SW8KZkfLFwn2G1+8pNDUsIkOY4qUSlnAiSlIsN0+ Y0KGoR/8LFTvntkyF8tjhQ3Wqd0+80VmDJgnW5xM+sflkBz0lfOjNUz/i5DyOohhGARTzybNCXMh LG7azDOx/Z7Rgw2VI1b9t3emtyC5UKdxnsRPe+4+ru5Iz654B6uxbA1wQV1Vas/MOaWF1EElmOvO 0+HBg9zzzKTvntEsQzRDWSTD2O/zKyPULPrQt5CiiH757qwoYYnL4OTEoLCeJI+TKptxlOROqOeu a2mb2hykFLDl+2ROnYiyB+TbzHIKQcuNLsC0eRknkiAlwsZjGNwPyWXrYWQoYakPV99oTFsRLU5b 7wqL0Zzbj9FG/zy//nTbJTVHS7slLGrbuy2iJAq5C0i5rZbmm7Gy3cbj8lnyB9SaJxmcUcPhhypL pWH9ggpcjyq/EhnIsbDd0yjgAkYixowulqMUtVnYnJBDYa9ndD2uwA7TgMMi1TduOr5dRiY7k2v7 QXFQluZT5fGgSsUMwDfxACKffoWxjjuJFSSWNI60fXoI0a2NHQbWp2nO0F69u7/CO0tNUloF+QXC mR5c3O/5RkW+/368PTS1ebyfmyrCp/h4cznd6atpSLkwGpeh2j4VrzAI+sgp8fQ/qoWzn8M0ObVE VBQps1T6kuWVC2ORZnHTZ3fBsFjpYFw9mISHTZR7zW81zXFB4urpk4+2TYgjSvov8Yray74Kh88T o7Qv1dQauB31YLHJfyYIDe2yPHcF+WndT/p0Ln25oXgtTvqp9+Pt7L7lAfxsTMou6te6ET3nr0nF HBDGqCaJ7FadrJaOIu5ksnAwssc0lFmiMFLlBf093Fjq98CW237Z7DdSnUNAIA2BKmkWdWcx6jaR R6mCob2HdAmJNjn3tBfNz3HqXDEhVQ9YEFCLX2WQ3CgbN+Er5VAuTyslbIAFYXIgRN3ZSOKXQWgO bcoJfcfDcayQXKyZ630/tBmHVB0NYuILstBsgsP7ksOW/sE3WAxfIWfjcRBbI+rLF3EULFiKVlv9 QeGfPfPwfqylPYF3tZjEqtvjX/wu/1b/14QQqpoehvVkFauJ+emax9Oze0uaTjHQFImY8NB5sVoR HLYmQG4ngJHyWnf5EqVZmgJifl2+8krkBBc5bKissOZ4fjffcOsslf3CwZZ8cdLfGBuEnPtubCVF 4m1FCGHPdTMhX/YnFtu5im3hzrOXA72F3scbeD21O/cFambNiVPycQcxjaVzPYLjwruPBz2O5Crm BKJt//4goVd4ZDfmsO4J5pSVnj+SujJjynMJE+U772m2Dlv6/Y+IfcFwPpfxgQiwoHI6idsxPwXC VWnKzmJsBIPUVIrnThNWwmb/q4RJtlJ6FQPw/qMV5nEPcP8DkG7xblAzKr5sbkgVQAG/uit5tJA/ slo+ZoxvtaqEEMixvSjjWeWFjp1sY71OeW2e7y/NqTP/q+sU5KWyLMnWbB1lEbTChScY67YlYffW GKfrnjnExOuYHpqf1A3AqkEiyKYTgEIvVpvBDSqmHsDOe7NejbPEIzzwKHcyatqLU330ELnUNamV cjAezejbSOPk65yp760LN5cCO4+NdNnO5e2BRP5t8AbU7vsZLzNOpRo2IaZV9BrV10mFGaNnCg60 kRKrvQ7QandMeLNEA5+XUCpYX93xLQSMkpjnkf1gQlwAQRnriL7MmxAbJGnwUvj2W5pc1nbyzw+z takbIwwEvqroNx9Yde2l+1JDSBYTU8JB3lOWJitgLc7WPpmWMaYK3qSRztElzB+vimbii72dVV8T DsC2pTskpBmSwkgBgZFDGglJ6QZp6WagDCRFGqS7YyMGI6RD/jC6O6Wke/A+73d4fs99fB1fJ9fB fZmQkjKSmE2WFuLOFr256c+dhyyYzCjD7Ito+P0KrukptJewqO3YxAnV/hhftsCkyGHUo1yRZJlu LHQyyF4lzZbpO6B5stlSTm9trD+gr0by2pU53oKZuQmXSeyyINC/Bo9RfBnIg9N896RLZApd2HmW 8g/9qQARpky/+rSpHCYtvO67+u3MtKgWxk819jmlyqiclj3CsDd41MMlL5Or/BUFWqIfUIuaqudh DUnH10huiPExbLn+TKCAa2wzgLzO9EzW1N68svSI/yWeFOFwb4IQLkEZF4GAjzM47SoegybHB1Vw xBBKRHQeAffOVv7x6MaL+rwowgLtJ7nVYug+leXLxHBEuISVSHJlXY4ddarxVJ0WbwF69lwfoLvk 6UWt1ToL0FhFG8ANpTMvJxaBsKCPwj7r08TOB0Kmk0eycIwtNDf21XzgMf9hQ6vW5c04vY9NEQu1 /Vu/nW3SE0zBYkoI8oK4Jli2sMHzr2UUu1faSLadAF3kc7ALtehupRaeNIUIby9ave7nygK5hHmR HGchi80067doc8DqudGf2Rod/wCOUMz8A1p7YC6LEKsuVr+e7Y/fXBxCSfvrb/wq2N5jWeXfc6e7 fpJm47hruodZE/Cd29HW2ucuulD4rAfttEEq/W1x9yhIxyBcrz7JU/lXT444U4/pfS1JS6gAsZMf vAgClsV4WskKu7GXzOz/XstQsYC4pFJ+9y3mL7jKSYixERW4gy7GsOMnDw5NAxsrkC/WZmaJi9gN Hi6lYSq6daSjPtn7rvO/VGTb2PMtJ2+e6NTrSgKXoQdWewnGIfyH2IdHZwfbCSOeBfu2/VPbrYbj WVSZrPTqAun6XUaCPY6r8mFaYRkzN0kI1jDtG/H2rmckY//MTIe1VCyx3NMRvzWPg+6oUsO7u2S8 1m/iRY9uuE0Xz41+u/+0r9wZHd48vItrEKAjZJM0koclNJDBKGOSQsazCGzEqJiHNaXSYPEro+w2 sdpGMNvxXBW7w6WLjtzDyt3DO6zOuav2cfc9038P2YATL8jJYXDtQ7s9P0y4WFBXYTVDO2Ngcr30 kfP0Esf5Y+qDVGIyHq4q0RJOaBEX/3ns9b4aQn1BTD7TFUt4TT6UOZGocLinHq7VQAJjnRtiqgn2 6whbFDXNfXd7YIOQGyR5W8bFlc2ED+F4nSb2E+69OBJWjOSbSWph7mJ6SQs0RBGX1DptoAWfOTUl Wx6d97VBIdGBRu76u+8pnpEu+C/7+5anEYRdtW8WJ8WPseP/3iv4HL9XnSvO2kzT8MyoZyVMd62X iOS/1I6P6A/KvsA3HpsVxCUgjsXf+uON3HdDXBhWdqzM9oHniXsNyAjqfrUdyZp3UU4WF8yHk2Rj 6ZtESTejOitiCVz2Pr18JZrO9b4J4YRQVZh4YQ5bJcdi3xmEZTYlnke0fLXxE8lDmfrKkA94+sXe f1WmQRdaW2XlZPMZ+oc8Uuw4It0RrPpt1aSeEjeM1OPOV8L3ZIM9V0SFecdkx4DdxNHP+InGwTUQ pVB/i4XK3oun5qpCTi3HJnLXM19Q84dXf9VqGJ9b0/SMPteWzciwofsNdTifcXhl8LpIeb0cSVIj MbPtqKLQA8t/cAxVw3XcOYhIWRvp5dokHRLmysDnbo+Xn8Ocsv2c4OA8E/pmhNaZ74HwnHCQJjVw kYBcMpQFJJ3BigueL9KcKwAVndsjVZJlpH1qjPV+gM2UuJ6iW7NoQX9WbjmrRynOssaPZzGvbidY rkqh8Z/5f+Cu/ag0wHg7qRvFkMKTul2/4qpq92xQr50ZP422siTbAf4sWIVHm8e3eDkc4Zhp2h8D 3BbjDME7S1CXVCKOcZt15xkAauNcIH6OZXGhapB3eP0FjFP6Bt3G0vMrdFWqxOQvaVxb5O/sFtHV k4CtE2OSOXll3Q8vKCjcok28UbaM1eivlrZkkUuOu6pKtilTOw7ps4MRxvQCDZohoTIWjoCLbrZh 7vM2ce/TMP6BqYVfaT6UV5tqUqGoRgyv4elWyBd2ux2FiLcYWAoE+gbimWY/wU11r0hbq8cG5suh 00iGtiqo86y0fZyLetAF1Mc6gm4rKtzVIGdozQtPteX1VrqUpxjU+b/1F7uAOo7GtlKHZzMneaAj CB7m6tXPtMU115w/Yye9m+RwFQTbdv4FGuv4xfShxKPDALW2wFRhQuWi8Ox7V1rkYuEAkH34UyRL KRP9De3Ii+ubln6kbOvfmyem2IJyuocX/1BoNqLDs9jXN4PQftSE8s4j92PkBIkBc8KdYvbmfNjs Mk5LCSKoD2pqmS9Ljo/1bO0zilL+cw1Yt4Qqj0xZF1itW7+UlEJOiD1YY1aj42lLRADl3mDuPNHr v7HCOeLvJMmzQb8rNX4eg2jfHLj30Am7NsKVhvFFjQWaCuP5QsD8IRZEBJpilY2d/u+HZCCPOyua qOtXfBgFeAEf0n4gREkSN3m9qRy5lkTcg3JqnUfwQQVeo9FGDBYrXoQj4DNNG2a6cqWW7sVaaUHv Xi+Wk0Ct1QUQEtj9sandZotoqqtS/LRtkVkjbH9iTw6kH6DXMshpUJ0/9j6Z1YpvTMvbWc9tiYwg lt/5e/i0jDi6oTEJNrI2Gl3/5X5CblLlNnAx6Lzz37M/A1I4MmclpPg7c3Ri8xdI0FO+SKOXvdfd RA/h5e3PnxtUoWr2z70J48TcC8lLSGDeTVcPYuOBOEKZS6+Kiw7Bdrs4dJGTGp+P2txOUMNtoRS/ CdsAmS2lYvdjQc3v53CKkiJ763bm2H03Zev0K5QbQwvXuCAAqz3up4F3vuEWGZ1Mb18ul6e3KBXo tKp36vpz+9nM0DNMLoSG7SP4mUQl8JFrl5dmlM8qIQ012EjSNx5whHYXZ4NvEh0E7vTmAqaF+GZl 2RiOLyN55ZtfnQ4OJcp3DaV6EOnrcVg0WX1U567CnjoE+1P998COBhbXpkUrIv9HKmsOH3sAcuGs p8BiZntY/o1LMQiHRMis9MvnjqSKORVNqLG6IlEqoddsFYOYekNW1EoJAH3cI/5pdeH/t8W9/rFG 6C1RVWQaA/F0/dss3ZXTihbAh/rcITJhQkzfFU3mvSobaF2j1Icvf6c+p3bOJwRw19nAbu9N/n6n iOYMnCjSqIY1Zu3uXwQprWzPtkaG9XPFlMKIKshX+GomlGRWKhCdVAuLybvAfZCp2QsF39yiTpeU OLxCbQ/sHOqlojk1qIiX57LMeB0fywBGwwewebNQFquEhHc7EBK+pcNICXQvokncNJdKM4262CRS 79Bi2uPv2q8uUDpyiVar+MAEQoAxxhdJtxwruvy+E/s1zfbR3buURS0k3Yta7QpSTmtwbkfYj5rC pzr8zgAlnUPSmHDNzD9UD/6lsocUXT8PmtBlP0pgEjKkn4J9D07Z5HHFIpZBsjT2pQkg4mSYRhCF gAzxSKfPi8YVD6E7VnECWkvqVP13h1Yt/4TBPvBiSefp0tAwBuULUaGmLz4V79hB68q+DnTOeEp9 5WtZ7kWiQl7n2OsjU/iMyWuG/QESsg05vwZ5oQJAi4wBuwj2FCGeajj9ufpGP3PV++qaVPU4e4aS MYyi/h7HyWWl95s+LjiS5T8KB1/bloMuj6BMF0AO55HzV+7DHWXABHEzTcv6Qowgs/E498IqVZ2X X48HLkT7sfTINC3vCHH0/zgx4Xo9ZsFpIlupklA3JD2xodmTivaOTdLL0qSj76SNc6cZ2ngKzLto d5EBY2LHOt0+/Vlkxm/sXygtJxgx9QcLXA0b8jVLY0gIBvG5/yualtakwcqBmyz+vsDXpkONGOef 5AbO41rwMFlH62z8FytUf4AJoZKBxd0oHF2Of1Xuzw2z1KFIIvlt8TxXwu5z7f32/OzynNrv/NLj jkHiRgAStS3wOblgT5qg+cS1I8Qt59iwOjqN8ZOD80662Zj2YdiVaqxG8X3xUHcpNMuD0+/3/f6I 0whN5AxJEZ54rgI8EjzArubUhA38ed1tOJtE3K5EumyzPxpJa+xmWmDnr2AfTOxEIXmelVBDHHTt 0UALD41bzuetSS7P/im2J7b95AllfIM6ITP6UXqmBfsH14FWNax2LGO7EfjVeMU8crg4CuAJ81d9 nCJkPfeyGKIKVXyQ/M5YqzAu0jv6gJBwUP5T5iYGUwCmvM3g2qD/RzVccw15dAm85H3jP5V10j1L Ak4q8UzDsCK6GrxA9wYwmBxmq4w5HUuABodmVRdPiJSNaAVuljD1w5npLMFxg6b23wgA7iMzNxae uvODz5e/ubdPOOjxjN2DJ4GVXH84WaC36rfJn1EUgu+e2rcirvTGK9sV2YaZj7SJzdpgk77/yuuK 32UoI/Aym2P0eSTJQc0o39OupuLFmRT3+9PUKykkdnDo84Mc9rDj3QGaMfcjms0QqxzyPtz/9jVj HfJZzArJfM21p1LfFxzwRQ5Ao7Sh3i9LzP01Tt6d1MFwOeG/A8x3pX+3csrM3v6bp6mZOFrJFAmi vAW/nYo0yTsWlmOSP00aeuj8Y3I8bBNQRQiVC45bbNyC+GlmzrSQffBF3AWPjy4YR5BnucQc9o8J to1OLvqJmEnJdbjXhgDMQ9a3WDqr2mtTGPOivS9pUnok5TNRXqZcITc4qKETxQv+jzX5NSwjD8Pk G92t0SZtk/w2lGeBTSxXYMeNQyjvaRSHPY9QT8b8OEMq9H3SRBo8d+vUmmZn7x3N7lmd+MiQOJoJ c+pNY/dNR/N5lZhs4r8XVyKyrqstWHQqVDVphZbi0VlwHQj5PRTUNnGRVk8YqlHfp0vp6Bmpdjd7 y5lkE31n+gvHvCaAu/derh53LTFbJLj5cYMwgCYzNtLO8mwqk/ivkCDNhWZxoOkbAKUvqeE3aDIA nlflkZ3noZ9tP2IA3JXa6pbubryPVGU5njprHEIlDaR9qeqgo997pbmxdX3N9jrZqlm4muJRUXlW LdviTr/aXZILaY8RM+xW8eWU6cNuhAxJtWNgHFefRkjxJEuO/LLzHv1seQR+1qWfhe7esIomwQbW QuXpZQqnhK2dEFKfikUf1X2zAmLDe1Aj9OVLKz5pGvIotEbead/137WxUymSR6XX4+PQ5Wd+jE5d evTLY4kZhOyylCgQxqp9/QXjW7iUFRMggUsZrkD46LwmvcHh6gUO5ZwC7Wikxn/0PPfOqo1Z1abA 5LPCu+WZ3XtXjjJf/igQB30lMuMvn4NiqtLAWGs+OP3reFDIiLX2OchXASbkrSM/0eUlXj3qW/sU jEGieLrRMLviNR3v2PpxJOvFbNafcmK5dpHiRvaDjfNTgBkS1R/HP3cY3Bt00QkReS2aEE9kA9LC KWo9tq4flq3lxXz6yvCsE8/U0f7ENyB7NYTtUM/SPc9fX1FZwHLiSi1nrD3GXjjmo3FsYJsT+zox ErWfa0QhlKI//u8gU3iRUxbxiw0w9YwzuDlsQEtu6dtQiHNPaGDQ5dhpe3DI4DTIo3rFNflrxjp6 lRsh9pVob7vfyyciHhc9veRiccug4bcRKbYF7xmg+OYjBSC/UfOsnnDqfI1m+ptziObj4bcAdFGA yXvCtY9pCDI6xno6V0k8qAM4emlxMtXBmL+1ok6wkxjVDBks/woulJUE1FeT26ltXDALNjNYOthE jLZHH+N2upbp0cRoDXsRRGceIk30Cnsx0ebbm6LL2syXokJde5JGpAKO7eqNZGVr26SD4jQyLR4e P+0ejZ2YLIgsPnMp5UJMByfUu9zmpICkS+CAGmrlqbawhlWMB7I9dz1VwxvgQmNtzXxWmLmMfggL c5rt/IZ0KWpahnq/N0ZDUPykdEKfLmaI4c3IuR+CXl9bHAyw1pIR1QmpE5tibzirfC4x0wqff29H XaXqCp8QWPjzUZHs0llbFijCLRe3nSfX3AfCcVZnXPeL3K074GR7fQctV3V5ZOK9rZode+oweMSy TxSnEJI7KVvXK1vf/n7c11eZt5kvGW+heMSFC0TrMaG5MzisJYWe9tLLHB7xaMk98K1Pe7TCf5dZ 0v4PrftbVlFbJoQzQxzzjGVXq7/8afwTZ0Omf8tD2VG15tID5/Xz6qtnHggZRdKzY1L0cZ/ZiBZB YN4snPwBYoEXSp25JtDyHKQvOCl5YVEohf7Bdq7cQ46p8jTz/O0JS6vp7PR//dPx/2r/DyRbpk4= --_006_2691CE0099834E4A9C5044EEC662BB9D452EDF24dfweml509mbxchi_-- ------------=_1384475442-1931-0-- From xuxiaohu@huawei.com Thu Nov 14 17:05:26 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3331D21E809F for ; Thu, 14 Nov 2013 17:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.073 X-Spam-Level: * X-Spam-Status: No, score=1.073 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs6QFjk4j5BM for ; Thu, 14 Nov 2013 17:05:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3821E808A for ; Thu, 14 Nov 2013 17:05:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH33327; Fri, 15 Nov 2013 01:05:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:04:10 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:05:10 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 09:04:59 +0800 From: Xuxiaohu To: "Yves Hertoghs (yhertogh)" , Lucy yong , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WWC4KAFdQQ1kU2Q/DHvWQzYVpoledVA Date: Fri, 15 Nov 2013 01:04:58 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962@NKGEML512-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJ?= =?gb2312?b?UFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 01:05:26 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhlIGZyYW1ld29yayBtZW50aW9uZWQgdHdvIGFwcHJvYWNoZXMgKHNlZSBiZWxvdyk6DQoNCklu IG9yZGVyIHRvIGdldCByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24sIE5WRXMgbWF5IGV4Y2hhbmdl DQogICAgICAgaW5mb3JtYXRpb24gZGlyZWN0bHkgYmV0d2VlbiB0aGVtc2VsdmVzIHZpYSBhIHBy b3RvY29sLiBJbiB0aGlzDQoNCg0KICAgIExhc3NlcnJlLCBldCBhbC4gICAgICAgIEV4cGlyZXMg TWF5IDEyLCAyMDE0ICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCg0KIDxodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW52bzMtZnJhbWV3b3JrLTA0I3BhZ2UtMTA+DQogICAg SW50ZXJuZXQtRHJhZnQgIEZyYW1ld29yayBmb3IgREMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiAg ICAgIE5vdmVtYmVyDQogICAgMjAxMw0KDQoNCiAgICAgICBjYXNlLCBhIGNvbnRyb2wgcGxhbmUg bW9kdWxlIHJlc2lkZXMgaW4gZXZlcnkgTlZFLiBUaGlzIGlzIGhvdw0KICAgICAgIHJvdXRpbmcg Y29udHJvbCBwbGFuZSBtb2R1bGVzIGFyZSBpbXBsZW1lbnRlZCBpbiByb3V0ZXJzIGZvcg0KICAg ICAgIGluc3RhbmNlLg0KDQogICAgICAgSXQgaXMgYWxzbyBwb3NzaWJsZSBmb3IgTlZFcyB0byBj b21tdW5pY2F0ZSB3aXRoIGFuIGV4dGVybmFsIE5ldHdvcmsNCiAgICAgICBWaXJ0dWFsaXphdGlv biBBdXRob3JpdHkgKE5WQSkgdG8gb2J0YWluIHJlYWNoYWJpbGl0eSBhbmQgZm9yd2FyZGluZw0K ICAgICAgIGluZm9ybWF0aW9uLiBJbiB0aGlzIGNhc2UsIGEgcHJvdG9jb2wgaXMgdXNlZCBiZXR3 ZWVuIE5WRXMgYW5kDQogICAgICAgTlZBKHMpIHRvIGV4Y2hhbmdlIGluZm9ybWF0aW9uLiBPcGVu RmxvdyBbT0ZdIGlzIG9uZSBleGFtcGxlIG9mIHN1Y2gNCiAgICAgICBhIHByb3RvY29sLg0KDQpO b3cgdGhlIGFyY2ggZHJhZnQgbWVudGlvbmVkIG9ubHkgdGhlIE5WRS1OVkEgaW50ZXJhY3Rpb24g YXBwcm9hY2guIERvZXMgaXQgbWVhbiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoZSBm cmFtZXdvcmsgZHJhZnQgaXMgc3RhbGU/DQoNClhpYW9odQ0KDQq3orz+yMs6IG52bzMtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBZdmVzIEhlcnRv Z2hzICh5aGVydG9naCkNCreiy83KsbzkOiAyMDEzxOoxMdTCMTXI1SAyOjE1DQrK1bz+yMs6IEx1 Y3kgeW9uZzsgWHV4aWFvaHU7IEJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KTsgbnZvM0BpZXRmLm9y Zw0K1vfM4jogUmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZv ciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpJIGRpc2FncmVlIHdpdGggdGhlIG5l ZWQgZm9yIGFuIE5WRSB0byBOVkUgY29udHJvbCBwbGFuZS4gIFRoYXQgZG9lc24ndCBtZWFuIHRo YXQgeW91IGNhbid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgZGlzdHJpYnV0ZWQgTlZBIHdp dGggZXZlcnkgTlZFLCB3aGljaCBpcyB0aGUgbW9kZWwgdGhhdCBlLmcuIEJHUC9MM1ZQTiBvciBJ U0lTL1RSSUxMIHVzZXMuDQoNCll2ZXMNCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVh d2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTQg Tm92ZW1iZXIgMjAxMyAxNjo1OQ0KVG86IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1h aWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4sIE1hdHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lA YWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNv bT4+LCAibnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3Jn PG1haWx0bzpudm8zQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cg YWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQN Cg0KSSBzaGFyZSBteSB2aWV3Lg0KDQpUaGUgY3VycmVudCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg aXMgbW9yZSBmb2N1c2luZyBvbiBOVkUtTlZBIGludGVyZmFjZSBhbmQgYXNzdW1lcyB0aGF0IE5W QSBpcyBhYmxlIHRvIG9idGFpbiBhbGwgVk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1h dGlvbqGvcyB0aGF0IGFuIE5WRSBuZWVkcy4gVGhhdCBkb2VzIGltcGxpY2l0bHkgaW5kaWNhdGUg dGhhdCBubyBjb250cm9sIHBsYW5lIHByb3RvY29sIGlzIG5lZWRlZCBiZXR3ZWVuIE5WRXMuIChO VkUtTlZFIGRhdGEgcGxhbmUgcHJvdG9jb2wgaXMgc3RpbGwgbmVlZGVkKS4gIEZyb20gdGhlIGFy Y2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgaWYgaXQgYWxsb3dzIHRoZSBjb250cm9sIHBsYW5lIHBy b3RvY29sIGV4aXN0IGJvdGggYmV0d2VlbiBOVkUtTlZBIGFuZCBOVkUtTlZFLCBpdCBtYXkgbGVh ZCB2ZXJ5IGNvbXBsZXggc29sdXRpb24gYW5kIG1hbnkgb3BlcmF0aW9uIGlzc3VlOyBpdCBoYXMg dG8gcmVzb2x2ZSB3aGljaCBpbmZvcm1hdGlvbiBOVkUgc2hvdWxkIHRydXN0IG9yIHVzZSwgaS5l LiBmcm9tIE5WQSBvciBmcm9tIE5WRS4NCg0KV2VhdGhlciB0aGlzIG1lYW5zIGV4Y2x1ZGluZyBU UklMTCBvciBTUEIsIGl0IGlzIGRlYmF0YWJsZS4gVGhlIGN1cnJlbnQgY2hhcnRlciBjbGVhcmx5 IHN0YXRlcyB0aGF0IE5WTzMgdGFyZ2V0cyBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXIgSVAg bmV0d29yay4gQmV5b25kIHRoaXMgcG9pbnQsIFRSSUxMIGhhcyBkaXJlY3RvcnkgYmFzZWQgc29s dXRpb24sIHdoaWNoIGZpdHMgaW50byBOVkUtTlZBIGFyY2hpdGVjdHVyZS4gIFNQQiBhbHNvIGhh dmUgU1BCLUVWUE4gc29sdXRpb24gdGhhdCBhbHNvIGFsaWducyB3aXRoIE5WRS1OVkEgYXJjaGl0 ZWN0dXJlLg0KDQpJTU86IE5WRS1OVkEgYmFzZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUg YW5kIE5WRS1OVkUgYmFzZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYXJlIGJvdGggcG9z c2libGUgZm9yIE5WTzMsIGJ1dCBub3QgdGhlIGNvbWJpbmVkIGFyY2hpdGVjdHVyZS4gQXMgeW91 IHNhaWQsIGl0IGlzIHRydWUgdGhhdCBOVkUtTlZFIGJhc2VkIGFyY2hpdGVjdHVyZSBpcyB1c2Vm dWwgaW4gc29tZSBzbWFsbCBhcHBsaWNhdGlvbnMuICBTaW5jZSBUUklMTCBhbmQgU0JQIGFscmVh ZHkgYWRkcmVzcyBpdCwgTlZPMyBzaG91bGQgb25seSBmb2N1cyBvbiB0aGUgTlZFLU5WQSBiYXNl ZCBhcmNoaXRlY3R1cmUuIE9uZSBvZiBOVk8zIGdvYWwgaXMgdGhlIHNjYWxhYmlsaXR5Lg0KDQpM dWN5DQoNCkZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnPiBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlh b2h1DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTQsIDIwMTMgMjo1OCBBTQ0KVG86IEJvY2Np LCBNYXR0aGV3IChNYXR0aGV3KTsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4N ClN1YmplY3Q6IFtudm8zXSC08Li0OiBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNr IGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpIaSBhbGwsDQoNCkluIHRoZSBj dXJyZW50IGFyY2ggZHJhZnQsIHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgTlZFLU5WRSBwcm90b2Nv bC4gRG9lcyBpdCBtZWFuIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCBmb3IgZGlyZWN0IGV4Y2hhbmdl IG9mIFZOIGFuZC9vciBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiBOVkVzPyBJ ZiBzbywgRG9lcyBpdCBtZWFuIHRoYXQgdGhlIGNvbnRyb2wgcGxhbmUgbWVjaGFuaXNtcyB1c2Vk IGJ5IFRSSUxMIG9yIFNQQiB3aGljaCBkZXBlbmQgb24gdGhlIE5WRS1OVkUgaW50ZXJhY3Rpb24g YXJlIG5vdCBzdWl0YWJsZSBmb3IgbXVsdGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzIGFu eW1vcmUsIGxlYXZpbmcgYXNpZGUgd2hldGhlciB0aGUgdW5kZXJsYXkgaXMgSVAgb3Igbm90Lg0K DQpJTUhPLCB0aGUgTlZFLU5WRSBwcm90b2NvbCBpcyBzdGlsbCB1c2VmdWwgaW4gc29tZSBzbWFs bCBhbmQgbWVkaXVtIHNpemVkIG11bHRpLXRlbmFudCBkYXRhIGNlbnRlciBuZXR3b3Jrcy4gQUZB SUssIG1vc3QgdGVuYW50cyB3aXRoaW4gcHVibGljIGNsb3VkIGRhdGEgY2VudGVycyBhcmUgc21h bGwgYW5kIG1lZGl1bSBzaXplZCBlbnRlcnByaXNlcyB3aGljaCB1c3VhbGx5IGRvbqGvdCBuZWVk IGEgbG90IG9mIFZNcy4gVGhhdCBtZWFucyB0aGUgbnVtYmVyIG9mIE5WRXMgZm9yIG1vc3QgVk5z IHdvdWxkIG5vdCBiZSB2ZXJ5IGxhcmdlIGVzcGVjaWFsbHkgaW4gdGhlIGNhc2Ugd2hlcmUgdGhl IE5WRSBpcyBkZXBsb3llZCBhdCBwaHlzaWNhbCBzd2l0Y2hlcywgcmF0aGVyIHRoYW4gaHlwZXJ2 aXNvcnMvc2VydmVycy4gSW4gdGhpcyBjYXNlLCB0aGUgVk4gbWVtYmVyc2hpcCBjYW4gYmUgZGlz Y292ZXJlZCB2aWEgSUdQIGZsb29kaW5nIGFuZCB0aGUgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0 aW9uIG9mIGEgZ2l2ZW4gVk4gY291bGQgYmUgZGlyZWN0bHkgZXhjaGFuZ2VkIGFtb25nIE5WRXMg b2YgdGhhdCBWTiwgd2l0aG91dCBhIG5lZWQgZm9yIGEgZGVkaWNhdGVkIE5WQS4NCg0KQmVzdCBy ZWdhcmRzLA0KWGlhb2h1DQoNCreivP7Iyzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52 bzMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddILT6se1C b2NjaSwgTWF0dGhldyAoTWF0dGhldykNCreiy83KsbzkOiAyMDEzxOoxMdTCMTPI1SAyMTo1OA0K ytW8/sjLOm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQrW98ziOiBbbnZvM10g UG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMt YXJjaC0wMS50eHQNCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAg dGhlIGNoYWlycyBqdWRnZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgIHRvIGFkb3B0IGRyYWZ0LW5h cnRlbi1udm8zLWFyY2gtMDEudHh0IGFzIGFuIE5WTzMgd29ya2luZyBncm91cCBkcmFmdC4NCg0K UGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCBvbiB0aGUgbGlzdCB3aXRoICdzdXBwb3J0JyBv ciAnZG8gbm90IHN1cHBvcnQnLg0KDQpQbGVhc2UgYWxzbyBzZW5kIGFueSBjb21tZW50cyBvbiB0 aGUgZHJhZnQgdG8gdGhlIE5WTzMgbGlzdC4NCg0KUGxlYXNlIGNvbnNpZGVyIHdoZXRoZXIgdGhp cyBkcmFmdCB0YWtlcyB0aGUgcmlnaHQgYmFzaWMgYXBwcm9hY2gsIGFuZCBpcyBhIGdvb2QgYmFz aXMgZm9yIHRoZSB3b3JrIGdvaW5nIGZvcndhcmQgKGFuZCBwb3RlbnRpYWwgZnV0dXJlIHJlY2hh cnRlcmluZykuIEl0IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHN0YWdlLg0K DQpDb2luY2lkZW50YWxseSwgd2UgYXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFu eSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMg YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZD cyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVz cG9uZCB0byB0aGlzIGVtYWlsIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUi4gVGhlIGRyYWZ0IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0K SWYgeW91IGFyZSBvbiB0aGUgTlZPMyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBh cyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9u ZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4g ZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhpcyBwb2xsIGNs b3NlcyBvbiBGcmlkYXkgMjl0aCBOb3ZlbWJlciAyMDEzLg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcg YW5kIEJlbnNvbg0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The framew= ork mentioned two approaches (see below):

= ;

In order to get reacha= bility information, NVEs may exchange

   &nbs= p;   information directly between themselves via a protocol. In t= his



   &nbs= p;

   &nbs= p;Lasserre, et al.        Expires May= 12, 2014           =        [Page 9]



   &nbs= p;Internet-Draft Framework for DC Network Virtualization &nbs= p;    November

    201= 3



   &nbs= p;

   &nbs= p;   case, a control plane module resides in every NVE. This= is how

   &nbs= p;   routing control plane modules are implemented in routers for=

   &nbs= p;   instance.



   &nbs= p;   It is also possible for NVEs to communicate with an ext= ernal Network

   &nbs= p;   Virtualization Authority (NVA) to obtain reachability and fo= rwarding

   &nbs= p;   information. In this case, a protocol is used between NVEs a= nd

   &nbs= p;   NVA(s) to exchange information. OpenFlow [OF] is one example= of such

   &nbs= p;   a protocol.

= ;

Now the ar= ch draft mentioned only the NVE-NVA interaction approach. Does it mean the = information contained in the framework draft is stale?
= ;

Xiaohu

= ;

=B7=A2=BC=FE=C8=CB: nvo3-bo= unces@ietf.org [mailto:nvo3-bounces@ietf.org] =B4=FA= =B1=ED Yves Hertoghs (yhertogh)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C215=C8=D5 2:15
=CA=D5=BC=FE=C8=CB: Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
=D6=F7=CC=E2: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-= 01.txt

I disagree w= ith the need for an NVE to NVE control plane. That doesn't mean that = you can't colocate a portion of the distributed NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.=

<= /o:p>

Yves

<= /o:p>

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

<= /o:p>

I share my= view.<= /p>

The curren= t architecture document is more focusing on NVE-NVA interface and assumes t= hat NVA is able to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather th= is means excluding TRILL or SPB, it is debatable. The current charter clear= ly states that NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits= into NVE-NVA architecture. SPB also have SPB-EVPN solution that also= aligns with NVE-NVA architecture.

IMO: NVE-N= VA based control plane architecture and NVE-NVE based control plane archite= cture are both possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01= .txt

Hi all,

In the cur= rent arch draft, there is no mention of NVE-NVE protocol. Does it mean that= there is no need for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control pla= ne mechanisms used by TRILL or SPB which depend on the NVE-NVE interaction = are not suitable for multi-tenant data center networks anymore, leaving asi= de whether the underlay is IP or not. <= /p>

IMHO, the = NVE-NVE protocol is still useful in some small and medium sized multi-tenan= t data center networks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually do= n=A1=AFt need a lot of VMs. That means the number of NVEs for most VNs woul= d not be very large especially in the case where the NVE is deployed at phy= sical switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regar= ds,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf= .org [mailto:nvo3-bounces@ietf.org= ] = =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C21= 3=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@ietf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.t= xt

This email begins a two week = poll to help the chairs judge if there is consensus to adopt dra= ft-narten-nvo3-arch-01.txt 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.

Please consider whether this = draft takes the right basic approach, and is a good basis for the work goin= g forward (and potential future rechartering). It does not have to be perfect at this stage.

Coincidentally, we are also p= olling 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 docume= nt author or contributor please respond to this email whether or not you ar= e 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 ema= il list but are not listed as an author or contributor, then please explici= tly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll closes on Friday 29= th November 2013.

Regards

Matthew and Benson

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962NKGEML512MBSchi_-- From xuxiaohu@huawei.com Thu Nov 14 17:39:35 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D94721E80FB for ; Thu, 14 Nov 2013 17:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF0uEfiD266A for ; Thu, 14 Nov 2013 17:39:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2B6721E80E2 for ; Thu, 14 Nov 2013 17:39:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH34973; Fri, 15 Nov 2013 01:39:19 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:38:54 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:39:14 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 09:39:05 +0800 From: Xuxiaohu To: "Yves Hertoghs (yhertogh)" , Lucy yong , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WWC4KAFdQQ1kU2Q/DHvWQzYVpoleuVQ Date: Fri, 15 Nov 2013 01:39:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987@NKGEML512-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJ?= =?gb2312?b?UFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 01:39:35 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCreivP7IyzogbnZvMy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnXSC0+rHtIFl2ZXMgSGVydG9naHMgKHloZXJ0b2doKQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx 1MIxNcjVIDI6MTUNCsrVvP7IyzogTHVjeSB5b25nOyBYdXhpYW9odTsgQm9jY2ksIE1hdHRoZXcg KE1hdHRoZXcpOyBudm8zQGlldGYub3JnDQrW98ziOiBSZTogW252bzNdIFBvbGwgZm9yIFdHIGFk b3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoN CkkgZGlzYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5l LiAgVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCB5b3UgY2FuJ3QgY29sb2NhdGUgYSBwb3J0aW9uIG9m IHRoZSBkaXN0cmlidXRlZCBOVkEgd2l0aCBldmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0 aGF0IGUuZy4gQkdQL0wzVlBOIG9yIElTSVMvVFJJTEwgdXNlcy4NCg0KDQpbWGlhb2h1XSBJbiB0 aGUgY2FzZSB3aGVyZSB0aGUgZGlzdHJpYnV0ZSBOVkEgaXMgZGVwbG95ZWQgYXQgZWFjaCBOVkUs IHdoYXShr3MgdGhlIG1lYW5pbmcgb2YgZGVmaW5pbmcgdGhlIE5WQS1OVkUgcHJvdG9jb2w/IElN SE8sIGFsbW9zdCBhbGwgdGhlIGRlc2NyaXB0aW9uIHdpdGhpbiB0aGUgYXJjaCBkcmFmdCBkb2Vz bqGvdCBjb25zaWRlciB0aGUgYWJvdmUgY2FzZSBhbmQgdGhlcmVmb3JlIGNvbmZsaWN0IHdpdGgg dGhhdCBjYXNlLiAgSWYgdGhlIFdHIGNvbnNlbnN1cyBpcyB0aGF0IHRoZSBhYm92ZSBjYXNlIGlz IHZhbGlkIGFzIHdlbGwsIGl0IHNob3VsZCBhdCBsZWFzdCBtZW50aW9uIHRoYXQgY2FzZSBleHBs aWNpdGx5IHNvbWV3aGVyZSBpbiB0aGUgZHJhZnQgYWx0aG91Z2ggdGhlIHdob2xlIGRyYWZ0IGlz IGZvY3VzZWQgIG9uIHRoZSBjZW50cmFsaXplZCBjb250cm9sbGVyKGkuZSwgTlZBKS1iYXNlZCBh cmNoaXRlY3R1cmUuDQoNClhpYW9odQ0KDQpZdmVzDQoNCkZyb206IEx1Y3kgeW9uZyA8bHVjeS55 b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCkRhdGU6IFRodXJz ZGF5IDE0IE5vdmVtYmVyIDIwMTMgMTY6NTkNClRvOiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2Vp LmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+LCBNYXR0aGV3IEJvY2NpIDxtYXR0aGV3 LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1 Y2VudC5jb20+PiwgIm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+IiA8bnZvM0Bp ZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW252bzNdIFBvbGwg Zm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gt MDEudHh0DQoNCkkgc2hhcmUgbXkgdmlldy4NCg0KVGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIGRv Y3VtZW50IGlzIG1vcmUgZm9jdXNpbmcgb24gTlZFLU5WQSBpbnRlcmZhY2UgYW5kIGFzc3VtZXMg dGhhdCBOVkEgaXMgYWJsZSB0byBvYnRhaW4gYWxsIFZOIGFuZC9vciBhZGRyZXNzIG1hcHBpbmcg aW5mb3JtYXRpb26hr3MgdGhhdCBhbiBOVkUgbmVlZHMuIFRoYXQgZG9lcyBpbXBsaWNpdGx5IGlu ZGljYXRlIHRoYXQgbm8gY29udHJvbCBwbGFuZSBwcm90b2NvbCBpcyBuZWVkZWQgYmV0d2VlbiBO VkVzLiAoTlZFLU5WRSBkYXRhIHBsYW5lIHByb3RvY29sIGlzIHN0aWxsIG5lZWRlZCkuICBGcm9t IHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUsIGlmIGl0IGFsbG93cyB0aGUgY29udHJvbCBw bGFuZSBwcm90b2NvbCBleGlzdCBib3RoIGJldHdlZW4gTlZFLU5WQSBhbmQgTlZFLU5WRSwgaXQg bWF5IGxlYWQgdmVyeSBjb21wbGV4IHNvbHV0aW9uIGFuZCBtYW55IG9wZXJhdGlvbiBpc3N1ZTsg aXQgaGFzIHRvIHJlc29sdmUgd2hpY2ggaW5mb3JtYXRpb24gTlZFIHNob3VsZCB0cnVzdCBvciB1 c2UsIGkuZS4gZnJvbSBOVkEgb3IgZnJvbSBOVkUuDQoNCldlYXRoZXIgdGhpcyBtZWFucyBleGNs dWRpbmcgVFJJTEwgb3IgU1BCLCBpdCBpcyBkZWJhdGFibGUuIFRoZSBjdXJyZW50IGNoYXJ0ZXIg Y2xlYXJseSBzdGF0ZXMgdGhhdCBOVk8zIHRhcmdldHMgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBv dmVyIElQIG5ldHdvcmsuIEJleW9uZCB0aGlzIHBvaW50LCBUUklMTCBoYXMgZGlyZWN0b3J5IGJh c2VkIHNvbHV0aW9uLCB3aGljaCBmaXRzIGludG8gTlZFLU5WQSBhcmNoaXRlY3R1cmUuICBTUEIg YWxzbyBoYXZlIFNQQi1FVlBOIHNvbHV0aW9uIHRoYXQgYWxzbyBhbGlnbnMgd2l0aCBOVkUtTlZB IGFyY2hpdGVjdHVyZS4NCg0KSU1POiBOVkUtTlZBIGJhc2VkIGNvbnRyb2wgcGxhbmUgYXJjaGl0 ZWN0dXJlIGFuZCBOVkUtTlZFIGJhc2VkIGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGFyZSBi b3RoIHBvc3NpYmxlIGZvciBOVk8zLCBidXQgbm90IHRoZSBjb21iaW5lZCBhcmNoaXRlY3R1cmUu IEFzIHlvdSBzYWlkLCBpdCBpcyB0cnVlIHRoYXQgTlZFLU5WRSBiYXNlZCBhcmNoaXRlY3R1cmUg aXMgdXNlZnVsIGluIHNvbWUgc21hbGwgYXBwbGljYXRpb25zLiAgU2luY2UgVFJJTEwgYW5kIFNC UCBhbHJlYWR5IGFkZHJlc3MgaXQsIE5WTzMgc2hvdWxkIG9ubHkgZm9jdXMgb24gdGhlIE5WRS1O VkEgYmFzZWQgYXJjaGl0ZWN0dXJlLiBPbmUgb2YgTlZPMyBnb2FsIGlzIHRoZSBzY2FsYWJpbGl0 eS4NCg0KTHVjeQ0KDQpGcm9tOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZz4gW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBYdXhpYW9odQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE0LCAyMDEzIDI6NTggQU0NClRv OiBCb2NjaSwgTWF0dGhldyAoTWF0dGhldyk7IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBbbnZvM10gtPC4tDogUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQ UiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSGkgYWxsLA0KDQpJ biB0aGUgY3VycmVudCBhcmNoIGRyYWZ0LCB0aGVyZSBpcyBubyBtZW50aW9uIG9mIE5WRS1OVkUg cHJvdG9jb2wuIERvZXMgaXQgbWVhbiB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yIGRpcmVjdCBl eGNoYW5nZSBvZiBWTiBhbmQvb3IgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9uIGJldHdlZW4g TlZFcz8gSWYgc28sIERvZXMgaXQgbWVhbiB0aGF0IHRoZSBjb250cm9sIHBsYW5lIG1lY2hhbmlz bXMgdXNlZCBieSBUUklMTCBvciBTUEIgd2hpY2ggZGVwZW5kIG9uIHRoZSBOVkUtTlZFIGludGVy YWN0aW9uIGFyZSBub3Qgc3VpdGFibGUgZm9yIG11bHRpLXRlbmFudCBkYXRhIGNlbnRlciBuZXR3 b3JrcyBhbnltb3JlLCBsZWF2aW5nIGFzaWRlIHdoZXRoZXIgdGhlIHVuZGVybGF5IGlzIElQIG9y IG5vdC4NCg0KSU1ITywgdGhlIE5WRS1OVkUgcHJvdG9jb2wgaXMgc3RpbGwgdXNlZnVsIGluIHNv bWUgc21hbGwgYW5kIG1lZGl1bSBzaXplZCBtdWx0aS10ZW5hbnQgZGF0YSBjZW50ZXIgbmV0d29y a3MuIEFGQUlLLCBtb3N0IHRlbmFudHMgd2l0aGluIHB1YmxpYyBjbG91ZCBkYXRhIGNlbnRlcnMg YXJlIHNtYWxsIGFuZCBtZWRpdW0gc2l6ZWQgZW50ZXJwcmlzZXMgd2hpY2ggdXN1YWxseSBkb26h r3QgbmVlZCBhIGxvdCBvZiBWTXMuIFRoYXQgbWVhbnMgdGhlIG51bWJlciBvZiBOVkVzIGZvciBt b3N0IFZOcyB3b3VsZCBub3QgYmUgdmVyeSBsYXJnZSBlc3BlY2lhbGx5IGluIHRoZSBjYXNlIHdo ZXJlIHRoZSBOVkUgaXMgZGVwbG95ZWQgYXQgcGh5c2ljYWwgc3dpdGNoZXMsIHJhdGhlciB0aGFu IGh5cGVydmlzb3JzL3NlcnZlcnMuIEluIHRoaXMgY2FzZSwgdGhlIFZOIG1lbWJlcnNoaXAgY2Fu IGJlIGRpc2NvdmVyZWQgdmlhIElHUCBmbG9vZGluZyBhbmQgdGhlIGFkZHJlc3MgbWFwcGluZyBp bmZvcm1hdGlvbiBvZiBhIGdpdmVuIFZOIGNvdWxkIGJlIGRpcmVjdGx5IGV4Y2hhbmdlZCBhbW9u ZyBOVkVzIG9mIHRoYXQgVk4sIHdpdGhvdXQgYSBuZWVkIGZvciBhIGRlZGljYXRlZCBOVkEuDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQq3orz+yMs6bnZvMy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3Jn XSC0+rHtQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpDQq3osvNyrG85DogMjAxM8TqMTHUwjEzyNUg MjE6NTgNCsrVvP7Iyzpudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0K1vfM4jog W252bzNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRl bi1udm8zLWFyY2gtMDEudHh0DQoNClRoaXMgZW1haWwgYmVnaW5zIGEgdHdvIHdlZWsgcG9sbCB0 byBoZWxwIHRoZSBjaGFpcnMganVkZ2UgaWYgdGhlcmUgaXMgY29uc2Vuc3VzICB0byBhZG9wdCBk cmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dCBhcyBhbiBOVk8zIHdvcmtpbmcgZ3JvdXAgZHJh ZnQuDQoNClBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgb24gdGhlIGxpc3Qgd2l0aCAnc3Vw cG9ydCcgb3IgJ2RvIG5vdCBzdXBwb3J0Jy4NCg0KUGxlYXNlIGFsc28gc2VuZCBhbnkgY29tbWVu dHMgb24gdGhlIGRyYWZ0IHRvIHRoZSBOVk8zIGxpc3QuDQoNClBsZWFzZSBjb25zaWRlciB3aGV0 aGVyIHRoaXMgZHJhZnQgdGFrZXMgdGhlIHJpZ2h0IGJhc2ljIGFwcHJvYWNoLCBhbmQgaXMgYSBn b29kIGJhc2lzIGZvciB0aGUgd29yayBnb2luZyBmb3J3YXJkIChhbmQgcG90ZW50aWFsIGZ1dHVy ZSByZWNoYXJ0ZXJpbmcpLiBJdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBz dGFnZS4NCg0KQ29pbmNpZGVudGFsbHksIHdlIGFyZSBhbHNvIHBvbGxpbmcgZm9yIGtub3dsZWRn ZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0LCB0byBlbnN1cmUgdGhhdCBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAo c2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKS4NCg0K SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxl YXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9m IGFueSByZWxldmFudCBJUFIuIFRoZSBkcmFmdCB3aWxsIG5vdCBiZSBhZG9wdGVkIHVudGlsIGEg cmVzcG9uc2UgaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0 b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIE5WTzMgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5 IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHll dCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoaXMg cG9sbCBjbG9zZXMgb24gRnJpZGF5IDI5dGggTm92ZW1iZXIgMjAxMy4NCg0KUmVnYXJkcw0KDQpN YXR0aGV3IGFuZCBCZW5zb24NCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

= ;

= ;

=B7=A2=BC=FE=C8=CB: nvo3-bo= unces@ietf.org [mailto:nvo3-bounces@ietf.org] =B4=FA= =B1=ED Yves Hertoghs (yhertogh)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C215=C8=D5 2:15
=CA=D5=BC=FE=C8=CB: Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
=D6=F7=CC=E2: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-= 01.txt

I disagree w= ith the need for an NVE to NVE control plane. That doesn't mean that = you can't colocate a portion of the distributed NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.=

= ;

[Xiaohu] In the case where the distribute NVA is deployed at each NV= E, what=A1=AFs the meaning of defining the NVA-NVE protocol? IMHO, almost a= ll the description within the arch draft doesn=A1=AFt consider the above ca= se and therefore conflict with that case. If the WG consensus is that= the above case is valid as well, it should at least mention that case expl= icitly somewhere in the draft although the whole draft is focused on = the centralized controller(i.e, NVA)-based architecture.<= /pre>
= ;

Xiaohu

<= /o:p>

Yves

<= /o:p>

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

<= /o:p>

I share my= view.<= /p>

The curren= t architecture document is more focusing on NVE-NVA interface and assumes t= hat NVA is able to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather th= is means excluding TRILL or SPB, it is debatable. The current charter clear= ly states that NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits= into NVE-NVA architecture. SPB also have SPB-EVPN solution that also= aligns with NVE-NVA architecture.

IMO: NVE-N= VA based control plane architecture and NVE-NVE based control plane archite= cture are both possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01= .txt

Hi all,

In the cur= rent arch draft, there is no mention of NVE-NVE protocol. Does it mean that= there is no need for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control pla= ne mechanisms used by TRILL or SPB which depend on the NVE-NVE interaction = are not suitable for multi-tenant data center networks anymore, leaving asi= de whether the underlay is IP or not. <= /p>

IMHO, the = NVE-NVE protocol is still useful in some small and medium sized multi-tenan= t data center networks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually do= n=A1=AFt need a lot of VMs. That means the number of NVEs for most VNs woul= d not be very large especially in the case where the NVE is deployed at phy= sical switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regar= ds,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf= .org [mailto:nvo3-bounces@ietf.org= ] = =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C21= 3=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@ietf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.t= xt

This email begins a two week = poll to help the chairs judge if there is consensus to adopt dra= ft-narten-nvo3-arch-01.txt 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.

Please consider whether this = draft takes the right basic approach, and is a good basis for the work goin= g forward (and potential future rechartering). It does not have to be perfect at this stage.

Coincidentally, we are also p= olling 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 docume= nt author or contributor please respond to this email whether or not you ar= e 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 ema= il list but are not listed as an author or contributor, then please explici= tly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll closes on Friday 29= th November 2013.

Regards

Matthew and Benson

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987NKGEML512MBSchi_-- From xuxiaohu@huawei.com Thu Nov 14 17:49:42 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298721E80F5 for ; Thu, 14 Nov 2013 17:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG60cdjIzquS for ; Thu, 14 Nov 2013 17:49:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 942D321E80F7 for ; Thu, 14 Nov 2013 17:49:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAH35499; Fri, 15 Nov 2013 01:49:35 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:48:32 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 01:49:34 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 09:49:24 +0800 From: Xuxiaohu To: Lucy yong , "Yves Hertoghs (yhertogh)" , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WWC4KAFdQQ1kU2Q/DHvWQzYVpokg0AAgAEA9yA= Date: Fri, 15 Nov 2013 01:49:23 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3@NKGEML512-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDC88@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452EDC88@dfweml509-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJ?= =?gb2312?b?UFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 01:49:42 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCreivP7IyzogTHVjeSB5b25nDQq3osvNyrG85DogMjAxM8TqMTHUwjE1yNUgMjoyMA0KytW8 /sjLOiBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCk7IFh1eGlhb2h1OyBCb2NjaSwgTWF0dGhldyAo TWF0dGhldyk7IG52bzNAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRv cHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0K WXZlcywNCg0KRnJvbTogbnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWXZl cyBIZXJ0b2docyAoeWhlcnRvZ2gpDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTQsIDIwMTMg MTI6MTUgUE0NClRvOiBMdWN5IHlvbmc7IFh1eGlhb2h1OyBCb2NjaSwgTWF0dGhldyAoTWF0dGhl dyk7IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW252 bzNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1u dm8zLWFyY2gtMDEudHh0DQoNCkkgZGlzYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRv IE5WRSBjb250cm9sIHBsYW5lLg0KW0x1Y3ldICBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZF IGNvbnRyb2wgcGxhbmU/IEkgZG9uoa90IHRoaW5rIHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBmcm9t IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50Lg0KIFRoYXQgZG9lc24ndCBtZWFuIHRoYXQgeW91IGNh bid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgZGlzdHJpYnV0ZWQgTlZBIHdpdGggZXZlcnkg TlZFLCB3aGljaCBpcyB0aGUgbW9kZWwgdGhhdCBlLmcuIEJHUC9MM1ZQTiBvciBJU0lTL1RSSUxM IHVzZXMuDQpbTHVjeV0gQWdyZWVkLiBOVkEgY2FuIGNvbGxvY2F0ZSB3LyBOVkUuIChwYXJ0aWFs bHkgb3IgZW50aXJlKS4NCg0KW1hpYW9odV0gSWYgdGhlIGFib3ZlIGFyZ3VtZW50IHdhcyBjb3Jy ZWN0LCBkb2VzIGl0IG1lYW4gdGhhdCB3ZSBjb3VsZCBzYXkgdGhhdCB0aGUgSW50ZXJuZXQgb25s eSBzdXBwb3J0cyBzb3VyY2Ugcm91dGluZyBzaW5jZSB0aGUgZGVzdGluYXRpb24tYmFzZWQgcm91 dGluZyBpcyBhIHNwZWNpZmljIGNhc2Ugb2YgdGhlIHNvdXJjZSByb3V0aW5nIChpLmUuLCB0aGUg ZGVzdGluYXRpb24gYWRkcmVzcyBpcyB0aGUgb25seSBleHBsaWNpdGx5IHNwZWNpZmllZCBob3Ag b2YgdGhlIGV4cGxpY2l0IHBhdGgpPyAgSU1ITywgb3Zlci1hYnN0cmFjdCB3aWxsIHJlc3VsdCBp biB1bm5lY2Vzc2FyeSBjb25mdXNpb25zLg0KDQpYaWFvaHUNCg0KDQpMdWN5DQoNCll2ZXMNCg0K RnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1 YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTQgTm92ZW1iZXIgMjAxMyAxNjo1OQ0KVG86IFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4s IE1hdHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpt YXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCAibnZvM0BpZXRmLm9yZzxtYWlsdG86 bnZvM0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPj4NClN1 YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3Ig ZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSSBzaGFyZSBteSB2aWV3Lg0KDQpUaGUg Y3VycmVudCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgbW9yZSBmb2N1c2luZyBvbiBOVkUtTlZB IGludGVyZmFjZSBhbmQgYXNzdW1lcyB0aGF0IE5WQSBpcyBhYmxlIHRvIG9idGFpbiBhbGwgVk4g YW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbqGvcyB0aGF0IGFuIE5WRSBuZWVkcy4g VGhhdCBkb2VzIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhhdCBubyBjb250cm9sIHBsYW5lIHByb3Rv Y29sIGlzIG5lZWRlZCBiZXR3ZWVuIE5WRXMuIChOVkUtTlZFIGRhdGEgcGxhbmUgcHJvdG9jb2wg aXMgc3RpbGwgbmVlZGVkKS4gIEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgaWYg aXQgYWxsb3dzIHRoZSBjb250cm9sIHBsYW5lIHByb3RvY29sIGV4aXN0IGJvdGggYmV0d2VlbiBO VkUtTlZBIGFuZCBOVkUtTlZFLCBpdCBtYXkgbGVhZCB2ZXJ5IGNvbXBsZXggc29sdXRpb24gYW5k IG1hbnkgb3BlcmF0aW9uIGlzc3VlOyBpdCBoYXMgdG8gcmVzb2x2ZSB3aGljaCBpbmZvcm1hdGlv biBOVkUgc2hvdWxkIHRydXN0IG9yIHVzZSwgaS5lLiBmcm9tIE5WQSBvciBmcm9tIE5WRS4NCg0K V2VhdGhlciB0aGlzIG1lYW5zIGV4Y2x1ZGluZyBUUklMTCBvciBTUEIsIGl0IGlzIGRlYmF0YWJs ZS4gVGhlIGN1cnJlbnQgY2hhcnRlciBjbGVhcmx5IHN0YXRlcyB0aGF0IE5WTzMgdGFyZ2V0cyBu ZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXIgSVAgbmV0d29yay4gQmV5b25kIHRoaXMgcG9pbnQs IFRSSUxMIGhhcyBkaXJlY3RvcnkgYmFzZWQgc29sdXRpb24sIHdoaWNoIGZpdHMgaW50byBOVkUt TlZBIGFyY2hpdGVjdHVyZS4gIFNQQiBhbHNvIGhhdmUgU1BCLUVWUE4gc29sdXRpb24gdGhhdCBh bHNvIGFsaWducyB3aXRoIE5WRS1OVkEgYXJjaGl0ZWN0dXJlLg0KDQpJTU86IE5WRS1OVkEgYmFz ZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYW5kIE5WRS1OVkUgYmFzZWQgY29udHJvbCBw bGFuZSBhcmNoaXRlY3R1cmUgYXJlIGJvdGggcG9zc2libGUgZm9yIE5WTzMsIGJ1dCBub3QgdGhl IGNvbWJpbmVkIGFyY2hpdGVjdHVyZS4gQXMgeW91IHNhaWQsIGl0IGlzIHRydWUgdGhhdCBOVkUt TlZFIGJhc2VkIGFyY2hpdGVjdHVyZSBpcyB1c2VmdWwgaW4gc29tZSBzbWFsbCBhcHBsaWNhdGlv bnMuICBTaW5jZSBUUklMTCBhbmQgU0JQIGFscmVhZHkgYWRkcmVzcyBpdCwgTlZPMyBzaG91bGQg b25seSBmb2N1cyBvbiB0aGUgTlZFLU5WQSBiYXNlZCBhcmNoaXRlY3R1cmUuIE9uZSBvZiBOVk8z IGdvYWwgaXMgdGhlIHNjYWxhYmlsaXR5Lg0KDQpMdWN5DQoNCkZyb206IG52bzMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52bzMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBUaHVyc2RheSwgTm92ZW1i ZXIgMTQsIDIwMTMgMjo1OCBBTQ0KVG86IEJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KTsgbnZvM0Bp ZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtudm8zXSC08Li0OiBQb2xs IGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNo LTAxLnR4dA0KDQpIaSBhbGwsDQoNCkluIHRoZSBjdXJyZW50IGFyY2ggZHJhZnQsIHRoZXJlIGlz IG5vIG1lbnRpb24gb2YgTlZFLU5WRSBwcm90b2NvbC4gRG9lcyBpdCBtZWFuIHRoYXQgdGhlcmUg aXMgbm8gbmVlZCBmb3IgZGlyZWN0IGV4Y2hhbmdlIG9mIFZOIGFuZC9vciBhZGRyZXNzIG1hcHBp bmcgaW5mb3JtYXRpb24gYmV0d2VlbiBOVkVzPyBJZiBzbywgRG9lcyBpdCBtZWFuIHRoYXQgdGhl IGNvbnRyb2wgcGxhbmUgbWVjaGFuaXNtcyB1c2VkIGJ5IFRSSUxMIG9yIFNQQiB3aGljaCBkZXBl bmQgb24gdGhlIE5WRS1OVkUgaW50ZXJhY3Rpb24gYXJlIG5vdCBzdWl0YWJsZSBmb3IgbXVsdGkt dGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzIGFueW1vcmUsIGxlYXZpbmcgYXNpZGUgd2hldGhl ciB0aGUgdW5kZXJsYXkgaXMgSVAgb3Igbm90Lg0KDQpJTUhPLCB0aGUgTlZFLU5WRSBwcm90b2Nv bCBpcyBzdGlsbCB1c2VmdWwgaW4gc29tZSBzbWFsbCBhbmQgbWVkaXVtIHNpemVkIG11bHRpLXRl bmFudCBkYXRhIGNlbnRlciBuZXR3b3Jrcy4gQUZBSUssIG1vc3QgdGVuYW50cyB3aXRoaW4gcHVi bGljIGNsb3VkIGRhdGEgY2VudGVycyBhcmUgc21hbGwgYW5kIG1lZGl1bSBzaXplZCBlbnRlcnBy aXNlcyB3aGljaCB1c3VhbGx5IGRvbqGvdCBuZWVkIGEgbG90IG9mIFZNcy4gVGhhdCBtZWFucyB0 aGUgbnVtYmVyIG9mIE5WRXMgZm9yIG1vc3QgVk5zIHdvdWxkIG5vdCBiZSB2ZXJ5IGxhcmdlIGVz cGVjaWFsbHkgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIE5WRSBpcyBkZXBsb3llZCBhdCBwaHlzaWNh bCBzd2l0Y2hlcywgcmF0aGVyIHRoYW4gaHlwZXJ2aXNvcnMvc2VydmVycy4gSW4gdGhpcyBjYXNl LCB0aGUgVk4gbWVtYmVyc2hpcCBjYW4gYmUgZGlzY292ZXJlZCB2aWEgSUdQIGZsb29kaW5nIGFu ZCB0aGUgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9uIG9mIGEgZ2l2ZW4gVk4gY291bGQgYmUg ZGlyZWN0bHkgZXhjaGFuZ2VkIGFtb25nIE5WRXMgb2YgdGhhdCBWTiwgd2l0aG91dCBhIG5lZWQg Zm9yIGEgZGVkaWNhdGVkIE5WQS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCreivP7Iyzpu dm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0 bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddILT6se1Cb2NjaSwgTWF0dGhldyAoTWF0dGhldykNCrei y83KsbzkOiAyMDEzxOoxMdTCMTPI1SAyMTo1OA0KytW8/sjLOm52bzNAaWV0Zi5vcmc8bWFpbHRv Om52bzNAaWV0Zi5vcmc+DQrW98ziOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQ UiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KVGhpcyBlbWFpbCBi ZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAgdGhlIGNoYWlycyBqdWRnZSBpZiB0aGVyZSBp cyBjb25zZW5zdXMgIHRvIGFkb3B0IGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0IGFzIGFu IE5WTzMgd29ya2luZyBncm91cCBkcmFmdC4NCg0KUGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCBvbiB0aGUgbGlzdCB3aXRoICdzdXBwb3J0JyBvciAnZG8gbm90IHN1cHBvcnQnLg0KDQpQbGVh c2UgYWxzbyBzZW5kIGFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQgdG8gdGhlIE5WTzMgbGlzdC4N Cg0KUGxlYXNlIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBkcmFmdCB0YWtlcyB0aGUgcmlnaHQgYmFz aWMgYXBwcm9hY2gsIGFuZCBpcyBhIGdvb2QgYmFzaXMgZm9yIHRoZSB3b3JrIGdvaW5nIGZvcndh cmQgKGFuZCBwb3RlbnRpYWwgZnV0dXJlIHJlY2hhcnRlcmluZykuIEl0IGRvZXMgbm90IGhhdmUg dG8gYmUgcGVyZmVjdCBhdCB0aGlzIHN0YWdlLg0KDQpDb2luY2lkZW50YWxseSwgd2UgYXJlIGFs c28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMg ZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5j ZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4 IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1 dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0IHdpbGwg bm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVh Y2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0aGUgTlZPMyBXRyBl bWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3Is IHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdp dGggSUVURiBydWxlcy4NCg0KVGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkgMjl0aCBOb3ZlbWJl ciAyMDEzLg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcgYW5kIEJlbnNvbg0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

= ;

= ;

=B7=A2=BC=FE=C8=CB: Lucy yo= ng
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C215=C8=D5 2:20
=CA=D5=BC=FE=C8=CB: Yves Hertoghs (yhertogh); Xuxiaohu; Bocci, Matthew (Matthew); nvo3@= ietf.org
=D6=F7=CC=E2: RE: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-= 01.txt

Yves,=

= ;

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Yves Hertoghs (yhertogh)
Sent: Thursday, November 14, 2013 12:15 PM
To: Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

I disagree w= ith the need for an NVE to NVE control plane.

[Luc= y] do you think we need NVE-NVE control plane? I don=A1=AFt think thi= s is what you mean from the following statement.<= /p>
That d= oesn't mean that you can't colocate a portion of the distributed NVA with e= very NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.

[Luc= y] Agreed. NVA can collocate w/ NVE. (partially or entire).

[Xia= ohu] If the above argum= ent was correct, does it mean that we could say that the Internet only supp= orts source routing since the destination-based routing is a specific case of the source routing (i.e., the destination address is= the only explicitly specified hop of the explicit path)? IMHO, over-= abstract will result in unnecessary confusions.

= ;

Xiaohu

Lucy= =

<= /o:p>

Yves

<= /o:p>

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

<= /o:p>

I share my= view.<= /p>

The curren= t architecture document is more focusing on NVE-NVA interface and assumes t= hat NVA is able to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather th= is means excluding TRILL or SPB, it is debatable. The current charter clear= ly states that NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits= into NVE-NVA architecture. SPB also have SPB-EVPN solution that also= aligns with NVE-NVA architecture.

IMO: NVE-N= VA based control plane architecture and NVE-NVE based control plane archite= cture are both possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01= .txt

Hi all,

In the cur= rent arch draft, there is no mention of NVE-NVE protocol. Does it mean that= there is no need for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control pla= ne mechanisms used by TRILL or SPB which depend on the NVE-NVE interaction = are not suitable for multi-tenant data center networks anymore, leaving asi= de whether the underlay is IP or not. <= /p>

IMHO, the = NVE-NVE protocol is still useful in some small and medium sized multi-tenan= t data center networks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually do= n=A1=AFt need a lot of VMs. That means the number of NVEs for most VNs woul= d not be very large especially in the case where the NVE is deployed at phy= sical switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regar= ds,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf= .org [mailto:nvo3-bounces@ietf.org= ] = =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C21= 3=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@ietf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.t= xt

This email begins a two week = poll to help the chairs judge if there is consensus to adopt dra= ft-narten-nvo3-arch-01.txt 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.

Please consider whether this = draft takes the right basic approach, and is a good basis for the work goin= g forward (and potential future rechartering). It does not have to be perfect at this stage.

Coincidentally, we are also p= olling 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 docume= nt author or contributor please respond to this email whether or not you ar= e 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 ema= il list but are not listed as an author or contributor, then please explici= tly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll closes on Friday 29= th November 2013.

Regards

Matthew and Benson

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3NKGEML512MBSchi_-- From kreeger@cisco.com Thu Nov 14 19:39:26 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B89611E8185 for ; Thu, 14 Nov 2013 19:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.753 X-Spam-Level: X-Spam-Status: No, score=-2.753 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD8SY6eBFKJ3 for ; Thu, 14 Nov 2013 19:39:19 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F41AD11E817E for ; Thu, 14 Nov 2013 19:39:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26047; q=dns/txt; s=iport; t=1384486759; x=1385696359; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=8Oylk2zRfqbABYVWBYNGV3r+TwVOWSBxQP+1auSOc1w=; b=c0ViCFp1npwWr02IbobooCybID4wpjgAAuRvjR6JCLcxEL9sK5JXq2bd vBHveUmHrzF5ruTY08H0SvtYFtKf/GJiBkLbVdtCjCwH0wyhj9vfc5nw6 LsHSXltu2TLgf2pf4k3Oh2RJX28u5ZYSlVeATJeGDzbIjMS0fVe+koR9T A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOWWhVKtJV2c/2dsb2JhbABZgkNEOFOCdrwnGIEJFnSCJQEBAQQtQwQXAQYCEQECAQEBIQcFBDAUAwYIAgQBEhuHZpJfm1gIklGOFoEuChcBBoJhgUoDmBCSDIMogXE5 X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208,217";a="284887680" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2013 03:39:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAF3dIU2016287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 03:39:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 21:39:17 -0600 From: "Larry Kreeger (kreeger)" To: "Yves Hertoghs (yhertogh)" , Lucy yong , Xuxiaohu , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WWA8z4hBe4/7k6wVW8qLGjOQpolc22A Date: Fri, 15 Nov 2013 03:39:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.155.166.41] Content-Type: multipart/alternative; boundary="_000_CEAAD61EBF892kreegerciscocom_" MIME-Version: 1.0 Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 03:39:26 -0000 --_000_CEAAD61EBF892kreegerciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWXZlcywNClNlZSBpbmxpbmUuIC0gTGFycnkNCg0KRnJvbTogIll2ZXMgSGVydG9naHMgKHlo ZXJ0b2doKSIgPHloZXJ0b2doQGNpc2NvLmNvbTxtYWlsdG86eWhlcnRvZ2hAY2lzY28uY29tPj4N CkRhdGU6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAxMToxNSBBTQ0KVG86IEx1Y3kgeW9u ZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sIFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4s ICJCb2NjaSwgTWF0dGhldyAoTWF0dGhldykiIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50 LmNvbTxtYWlsdG86bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20+PiwgIm52bzNAaWV0 Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+IiA8bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW252bzNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJ UFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkkgZGlzYWdyZWUg d2l0aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KDQpMSz4gWXZl cywgaW4gc2VjdGlvbiAzLjIuNS4yIG9mIGRyYWZ0LWhlcnRvZ2hzLW52bzMtbGlzcC1jb250cm9s cGxhbmUtdW5pZmllZC0wMCAobmVhciB0aGUgYm90dG9tIG9mIHBhZ2UgMTEpLCBpdCBkZXNjcmli ZXMgYW4gRVRSIHNlbmRpbmcgYSBTb2xpY2l0IE1hcCBSZXF1ZXN0IG1lc3NhZ2UgdG8gYW4gSVRS IGRpcmVjdGx5LiAgR2l2ZW4gdGhpcywgd2h5IGRvIHlvdSBkaXNhZ3JlZSBzaW5jZSB5b3VyIG93 biBkcmFmdCBkZXNjcmliZXMgYW4gTlZFIHNlbmRpbmcgYSBjb250cm9sIG1lc3NhZ2UgdG8gYW5v dGhlciBOVkU/DQoNCiBUaGF0IGRvZXNuJ3QgbWVhbiB0aGF0IHlvdSBjYW4ndCBjb2xvY2F0ZSBh IHBvcnRpb24gb2YgdGhlIGRpc3RyaWJ1dGVkIE5WQSB3aXRoIGV2ZXJ5IE5WRSwgd2hpY2ggaXMg dGhlIG1vZGVsIHRoYXQgZS5nLiBCR1AvTDNWUE4gb3IgSVNJUy9UUklMTCB1c2VzLg0KDQpZdmVz DQoNCkZyb206IEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9u Z0BodWF3ZWkuY29tPj4NCkRhdGU6IFRodXJzZGF5IDE0IE5vdmVtYmVyIDIwMTMgMTY6NTkNClRv OiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNv bT4+LCBNYXR0aGV3IEJvY2NpIDxtYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWls dG86bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb20+PiwgIm52bzNAaWV0Zi5vcmc8bWFp bHRvOm52bzNAaWV0Zi5vcmc+IiA8bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW252bzNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sg Zm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkkgc2hhcmUgbXkgdmlldy4NCg0K VGhlIGN1cnJlbnQgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGlzIG1vcmUgZm9jdXNpbmcgb24gTlZF LU5WQSBpbnRlcmZhY2UgYW5kIGFzc3VtZXMgdGhhdCBOVkEgaXMgYWJsZSB0byBvYnRhaW4gYWxs IFZOIGFuZC9vciBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb26hr3MgdGhhdCBhbiBOVkUgbmVl ZHMuIFRoYXQgZG9lcyBpbXBsaWNpdGx5IGluZGljYXRlIHRoYXQgbm8gY29udHJvbCBwbGFuZSBw cm90b2NvbCBpcyBuZWVkZWQgYmV0d2VlbiBOVkVzLiAoTlZFLU5WRSBkYXRhIHBsYW5lIHByb3Rv Y29sIGlzIHN0aWxsIG5lZWRlZCkuICBGcm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmUs IGlmIGl0IGFsbG93cyB0aGUgY29udHJvbCBwbGFuZSBwcm90b2NvbCBleGlzdCBib3RoIGJldHdl ZW4gTlZFLU5WQSBhbmQgTlZFLU5WRSwgaXQgbWF5IGxlYWQgdmVyeSBjb21wbGV4IHNvbHV0aW9u IGFuZCBtYW55IG9wZXJhdGlvbiBpc3N1ZTsgaXQgaGFzIHRvIHJlc29sdmUgd2hpY2ggaW5mb3Jt YXRpb24gTlZFIHNob3VsZCB0cnVzdCBvciB1c2UsIGkuZS4gZnJvbSBOVkEgb3IgZnJvbSBOVkUu DQoNCldlYXRoZXIgdGhpcyBtZWFucyBleGNsdWRpbmcgVFJJTEwgb3IgU1BCLCBpdCBpcyBkZWJh dGFibGUuIFRoZSBjdXJyZW50IGNoYXJ0ZXIgY2xlYXJseSBzdGF0ZXMgdGhhdCBOVk8zIHRhcmdl dHMgbmV0d29yayB2aXJ0dWFsaXphdGlvbiBvdmVyIElQIG5ldHdvcmsuIEJleW9uZCB0aGlzIHBv aW50LCBUUklMTCBoYXMgZGlyZWN0b3J5IGJhc2VkIHNvbHV0aW9uLCB3aGljaCBmaXRzIGludG8g TlZFLU5WQSBhcmNoaXRlY3R1cmUuICBTUEIgYWxzbyBoYXZlIFNQQi1FVlBOIHNvbHV0aW9uIHRo YXQgYWxzbyBhbGlnbnMgd2l0aCBOVkUtTlZBIGFyY2hpdGVjdHVyZS4NCg0KSU1POiBOVkUtTlZB IGJhc2VkIGNvbnRyb2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGFuZCBOVkUtTlZFIGJhc2VkIGNvbnRy b2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGFyZSBib3RoIHBvc3NpYmxlIGZvciBOVk8zLCBidXQgbm90 IHRoZSBjb21iaW5lZCBhcmNoaXRlY3R1cmUuIEFzIHlvdSBzYWlkLCBpdCBpcyB0cnVlIHRoYXQg TlZFLU5WRSBiYXNlZCBhcmNoaXRlY3R1cmUgaXMgdXNlZnVsIGluIHNvbWUgc21hbGwgYXBwbGlj YXRpb25zLiAgU2luY2UgVFJJTEwgYW5kIFNCUCBhbHJlYWR5IGFkZHJlc3MgaXQsIE5WTzMgc2hv dWxkIG9ubHkgZm9jdXMgb24gdGhlIE5WRS1OVkEgYmFzZWQgYXJjaGl0ZWN0dXJlLiBPbmUgb2Yg TlZPMyBnb2FsIGlzIHRoZSBzY2FsYWJpbGl0eS4NCg0KTHVjeQ0KDQpGcm9tOm52bzMtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMTQsIDIwMTMgMjo1OCBBTQ0KVG86IEJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KTsgbnZv M0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtudm8zXSC08Li0OiBQ b2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1h cmNoLTAxLnR4dA0KDQpIaSBhbGwsDQoNCkluIHRoZSBjdXJyZW50IGFyY2ggZHJhZnQsIHRoZXJl IGlzIG5vIG1lbnRpb24gb2YgTlZFLU5WRSBwcm90b2NvbC4gRG9lcyBpdCBtZWFuIHRoYXQgdGhl cmUgaXMgbm8gbmVlZCBmb3IgZGlyZWN0IGV4Y2hhbmdlIG9mIFZOIGFuZC9vciBhZGRyZXNzIG1h cHBpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiBOVkVzPyBJZiBzbywgRG9lcyBpdCBtZWFuIHRoYXQg dGhlIGNvbnRyb2wgcGxhbmUgbWVjaGFuaXNtcyB1c2VkIGJ5IFRSSUxMIG9yIFNQQiB3aGljaCBk ZXBlbmQgb24gdGhlIE5WRS1OVkUgaW50ZXJhY3Rpb24gYXJlIG5vdCBzdWl0YWJsZSBmb3IgbXVs dGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzIGFueW1vcmUsIGxlYXZpbmcgYXNpZGUgd2hl dGhlciB0aGUgdW5kZXJsYXkgaXMgSVAgb3Igbm90Lg0KDQpJTUhPLCB0aGUgTlZFLU5WRSBwcm90 b2NvbCBpcyBzdGlsbCB1c2VmdWwgaW4gc29tZSBzbWFsbCBhbmQgbWVkaXVtIHNpemVkIG11bHRp LXRlbmFudCBkYXRhIGNlbnRlciBuZXR3b3Jrcy4gQUZBSUssIG1vc3QgdGVuYW50cyB3aXRoaW4g cHVibGljIGNsb3VkIGRhdGEgY2VudGVycyBhcmUgc21hbGwgYW5kIG1lZGl1bSBzaXplZCBlbnRl cnByaXNlcyB3aGljaCB1c3VhbGx5IGRvbqGvdCBuZWVkIGEgbG90IG9mIFZNcy4gVGhhdCBtZWFu cyB0aGUgbnVtYmVyIG9mIE5WRXMgZm9yIG1vc3QgVk5zIHdvdWxkIG5vdCBiZSB2ZXJ5IGxhcmdl IGVzcGVjaWFsbHkgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIE5WRSBpcyBkZXBsb3llZCBhdCBwaHlz aWNhbCBzd2l0Y2hlcywgcmF0aGVyIHRoYW4gaHlwZXJ2aXNvcnMvc2VydmVycy4gSW4gdGhpcyBj YXNlLCB0aGUgVk4gbWVtYmVyc2hpcCBjYW4gYmUgZGlzY292ZXJlZCB2aWEgSUdQIGZsb29kaW5n IGFuZCB0aGUgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9uIG9mIGEgZ2l2ZW4gVk4gY291bGQg YmUgZGlyZWN0bHkgZXhjaGFuZ2VkIGFtb25nIE5WRXMgb2YgdGhhdCBWTiwgd2l0aG91dCBhIG5l ZWQgZm9yIGEgZGVkaWNhdGVkIE5WQS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCreivP7I yzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddILT6se1Cb2NjaSwgTWF0dGhldyAoTWF0dGhldykN Creiy83KsbzkOiAyMDEzxOoxMdTCMTPI1SAyMTo1OA0KytW8/sjLOm52bzNAaWV0Zi5vcmc8bWFp bHRvOm52bzNAaWV0Zi5vcmc+DQrW98ziOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5k IElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KVGhpcyBlbWFp bCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAgdGhlIGNoYWlycyBqdWRnZSBpZiB0aGVy ZSBpcyBjb25zZW5zdXMgIHRvIGFkb3B0IGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0IGFz IGFuIE5WTzMgd29ya2luZyBncm91cCBkcmFmdC4NCg0KUGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBl bWFpbCBvbiB0aGUgbGlzdCB3aXRoICdzdXBwb3J0JyBvciAnZG8gbm90IHN1cHBvcnQnLg0KDQpQ bGVhc2UgYWxzbyBzZW5kIGFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQgdG8gdGhlIE5WTzMgbGlz dC4NCg0KUGxlYXNlIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBkcmFmdCB0YWtlcyB0aGUgcmlnaHQg YmFzaWMgYXBwcm9hY2gsIGFuZCBpcyBhIGdvb2QgYmFzaXMgZm9yIHRoZSB3b3JrIGdvaW5nIGZv cndhcmQgKGFuZCBwb3RlbnRpYWwgZnV0dXJlIHJlY2hhcnRlcmluZykuIEl0IGRvZXMgbm90IGhh dmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHN0YWdlLg0KDQpDb2luY2lkZW50YWxseSwgd2UgYXJl IGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRo aXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50 IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdoZXRo ZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0IHdp bGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9t IGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0aGUgTlZPMyBX RyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0 b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUg b2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNl IHdpdGggSUVURiBydWxlcy4NCg0KVGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkgMjl0aCBOb3Zl bWJlciAyMDEzLg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcgYW5kIEJlbnNvbg0KDQo= --_000_CEAAD61EBF892kreegerciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <1CCC51382FEE0B45918C17BE9527B0D8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Yves,

See inline. - Larry

From: "Yves Hertoghs (yhertogh= )" <yhertogh@cisco.com>= ;
Date: Thursday, November 14, 2013 1= 1:15 AM
To: Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "Bocci, M= atthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I disagree with the need for an NVE to NVE control plane.

LK> Yves, in section 3.2.5.2 of draft-hertoghs-nvo3-lisp-contr= olplane-unified-00 (near the bottom of page 11), it describes an ETR sendin= g a Solicit Map Request message to an ITR directly. Given this, why d= o you disagree since your own draft describes an NVE sending a control message to another NVE?

That doesn't mean that you can't colocate a portion of the distr= ibuted NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/T= RILL uses.

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:= 59
To: Xuxiaohu <xuxiaohu@huawei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.c= om>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I share my view.=

The current architecture document = is more focusing on NVE-NVA interface and assumes that NVA is able to obtai= n all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather this means excluding TRILL= or SPB, it is debatable. The current charter clearly states that NVO3 targ= ets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE= -NVA architecture. SPB also have SPB-EVPN solution that also aligns w= ith NVE-NVA architecture.

IMO: NVE-NVA based control plane a= rchitecture and NVE-NVE based control plane architecture are both possible = for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From:nvo3-bou= nces@ietf.org [mailto:nvo3-bou= nces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for d= raft-narten-nvo3-arch-01.txt

Hi all,

In the current arch draft, there i= s no mention of NVE-NVE protocol. Does it mean that there is no need for di= rect exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mecha= nisms used by TRILL or SPB which depend on the NVE-NVE interaction are not = suitable for multi-tenant data center networks anymore, leaving aside wheth= er the underlay is IP or not.

IMHO, the NVE-NVE protocol is stil= l useful in some small and medium sized multi-tenant data center networks. = AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1= =AFt need a lot of VMs. That means the number of NVEs for most VNs would no= t be very large especially in the case where the NVE is deployed at physica= l switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regards,
Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.= org [mailto:nvo3-bounces@ietf.org= ] =B4= =FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA= 11=D4=C213= =C8=D5 21:58
=CA=D5=BC=FE=C8=CB:= nvo3@ietf.org
=D6=F7=CC=E2: [nvo3= ] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt=

T= his email begins a two week poll to help the chairs judge if there is conse= nsus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working g= roup draft.

P= lease respond to this email on the list with 'support' or 'do not support'.=

P= lease also send any comments on the draft to the NVO3 list.

P= lease consider whether this draft takes the right basic approach, and is a = good basis for the work going forward (and potential future rechartering). = It does not have to be perfect at this stage.

C= oincidentally, 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).

I= f 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.

I= f you are on the NVO3 WG email list but are not listed as an author or cont= ributor, then please explicitly respond only if you are aware of any IPR th= at has not yet been disclosed in conformance with IETF rules.

T= his poll closes on Friday 29th November 2013.

R= egards

M= atthew and Benson

--_000_CEAAD61EBF892kreegerciscocom_-- From lizho.jin@gmail.com Fri Nov 15 00:20:47 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C73911E80F6 for ; Fri, 15 Nov 2013 00:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XWm4KgCuxNL for ; Fri, 15 Nov 2013 00:20:47 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id DCA7611E80DC for ; Fri, 15 Nov 2013 00:20:46 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so260199pdi.38 for ; Fri, 15 Nov 2013 00:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=bS8VUke/+b/YIrXz6ejORrCa5A/1w1qChniCW3+yrLM=; b=LCesQPhFR6h6u4mXIq0pAAO/7HQAU4OtnP9l7l892eOC1MiIDUqlKgRjY3+1vMbYGr pzkf7KHUhVP8Mfn30HhlpyYX7ZtNFuaoqF+GQx9ycRH50Okr11hIHUNMnERX/pn8BC5k O3E3N7H2DbfOvdVfgWvc+nr4kcxZrBcyFXyt4c/y/8i1Z8/6L9QcK81o4rsPjoAFcmj4 ctu15o9fTZNj6BZ+ZMbbvfvuTw2CLmnqRZZ7zlUbJE89QSB2aRiZ15F7VQWcfEi4zzex 4TPqXIM2MajWxeo0hibcKipUc+HjnNRNgMkY5ux0COQFWgclyDZckVoSmNfMc2Gf/ixH nYxQ== X-Received: by 10.68.231.105 with SMTP id tf9mr5792423pbc.4.1384503646617; Fri, 15 Nov 2013 00:20:46 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id ik1sm2799745pbc.9.2013.11.15.00.20.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Nov 2013 00:20:45 -0800 (PST) From: "Lizhong Jin" To: "'Bocci, Matthew $Matthew$'" , Date: Fri, 15 Nov 2013 16:20:40 +0800 Message-ID: <0d1c01cee1db$949eb700$bddc2500$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D1D_01CEE21E.A2C30870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7h24XHKfHwsyzhR7iXBqojBdyz+A== Content-Language: zh-cn Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:20:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D1D_01CEE21E.A2C30870 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Yes, support. =20 Lizhong =20 From: Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcatel-lucent.com] = Sent: 2013=C4=EA11=D4=C213=C8=D5 21:58 To: nvo3@ietf.org Subject: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt =20 This email begins a two week poll to help the chairs judge if there is consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working = group draft. =20 Please respond to this email on the list with 'support' or 'do not = support'. =20 Please also send any comments on the draft to the NVO3 list. =20 Please consider whether this draft takes the right basic approach, and = is a good basis for the work going forward (and potential future = rechartering). It does not have to be perfect at this stage. =20 Coincidentally, 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). =20 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. =20 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. =20 This poll closes on Friday 29th November 2013. =20 Regards =20 Matthew and Benson =20 ------=_NextPart_000_0D1D_01CEE21E.A2C30870 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Yes, support.

Lizhong

From:= = Bocci, Matthew (Matthew) [mailto:matthew.bocci@alcatel-lucent.com] =
Sent: 2013=C4=EA11=D4=C213=C8=D5 = 21:58
To: nvo3@ietf.org
Subject: [nvo3] Poll for WG = adoption and IPR check for = draft-narten-nvo3-arch-01.txt

This email begins a two = week poll to help the chairs judge if there is consensus to = adopt draft-narten-nvo3-arch-01.txt 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.

Please consider whether = this draft takes the right basic approach, and is a good basis for the = work going forward (and potential future rechartering). It does not have = to be perfect at this stage.

Coincidentally, 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 Friday = 29th November 2013.

Regards

Matthew and = Benson

------=_NextPart_000_0D1D_01CEE21E.A2C30870-- From yhertogh@cisco.com Fri Nov 15 00:33:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9E721F93BA for ; Fri, 15 Nov 2013 00:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCjRh-bQKJ-r for ; Fri, 15 Nov 2013 00:33:50 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1944721F9A59 for ; Fri, 15 Nov 2013 00:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30437; q=dns/txt; s=iport; t=1384504430; x=1385714030; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=6ZZ3zdM1jOKX88AWa/v6H2Idglz5HCgl/+iJXTkd8f8=; b=j7smGR/BSjZyJdnq7iB14CrGfFpdLjME20Dmulfdc+ht9gbLD3NNcy6q UtmlSnuzUoJAnVv9wH2wVaAV+U/aTBXJd9dsuBtA3zde6sFY3Ri+gPTt5 1yqTC/6v06jZ07Lzgaw/MpD62ybQO8eTzeVcThhpyQyV+gesPfPvyhNEE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJPbhVKtJV2c/2dsb2JhbABagkNEOFOCdrwsGIEKFnSCJQEBAQQtQwQXAQYCEQECAQEBIQcFBDAUAwYIAgQBEhuHZpI4m1gIkkyOFhEBgR8KFwEGgmGBSgOYEJIMgyiBcTk X-IronPort-AV: E=Sophos;i="4.93,706,1378857600"; d="scan'208,217";a="285242462" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2013 08:33:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAF8Xn6Q022307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 08:33:49 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 02:33:48 -0600 From: "Yves Hertoghs (yhertogh)" To: "Larry Kreeger (kreeger)" , Lucy yong , Xuxiaohu , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WV1DP5gnDdPXkCW3GaWiHBP05omCk+AgABjDIA= Date: Fri, 15 Nov 2013 08:33:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.61.203.14] Content-Type: multipart/alternative; boundary="_000_CEAB99BE28433yhertoghciscocom_" MIME-Version: 1.0 Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 08:33:56 -0000 --_000_CEAB99BE28433yhertoghciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 TGFycnksDQoNCkkgZ3Vlc3MgdGhpcyBpcyB3aGVyZSB0aGUgYWJzdHJhY3Rpb24gdGhhdCBYaWFo b3UgaXMgcmVmZXJyaW5nIHRvIGNhbiBsZWFkIHRvIGNvbmZ1c2lvbi4gIEluIExJU1AgdGhlIE5W QSBmdW5jdGlvbiBpcyBtb3N0bHkgbG9naWNhbGx5IGNlbnRyYWxpc2VkLCBob3dldmVyIHRoZSBs b2NhbCBjYWNoZSBhdCB0aGUgeFRSJ3MgYXJlIGF1dGhvcml0YXRpdmUgYXMgd2VsbCBpLmUuIFRo ZXkgY2FuIGJlIHNlZW4gYXMgYW4gZXh0ZW5zaW9uIG9mIHRoZSBOVkEgZnVuY3Rpb24uICBUaGlz IGlzIGhvdyBERFQgb3BlcmF0ZXMsIHRoZSB4VFIncyBjYW4gYmUgcGFydCBvZiB0aGUgRERUIGxv b2t1cCAodmVyeSBzaW1pbGFyIHRvIGEgRE5TKS4NCg0KU28gcGVyaGFwcyBteSBxdWVzdGlvbiBp cyBub3c6IGFyZSB0aGUgTlZFIGFuZCBOVkEgZW50aXRpdGllcyB0aGF0IHdlIGFyZSB0YWxraW5n IGFib3V0IG5vZGVzLCBvciBmdW5jdGlvbnMgd2l0aGluIGEgbm9kZT8NCkJhc2VkIG9uIG15IHVu ZGVyc3RhbmRpbmcgaXQgaXMgdGhlIGxhdHRlciwgaGVuY2UgbXkgaW50ZXJwcmV0YXRpb24gdGhh dCB0aGUgcHVyZSBOVkUgJ2Z1bmN0aW9uJyBkb2VzIG5vdCBuZWVkIGEgY29udHJvbC1wbGFuZSB0 byBpbnRlcmFjdCB3aXRoIHRoZSBOVkUgZnVuY3Rpb24gb24gYW5vdGhlciBub2RlLCBhbHRob3Vn aCBpdCBjb3VsZCBpbnRlcmFjdCB3aXRoIHRoZSBOVkEgZnVuY3Rpb24gcmVzaWRlbnQgb24gdGhl IHNhbWUgbm9kZS4NCg0KWXZlcw0KDQpGcm9tOiAiTGFycnkgS3JlZWdlciAoa3JlZWdlcikiIDxr cmVlZ2VyQGNpc2NvLmNvbTxtYWlsdG86a3JlZWdlckBjaXNjby5jb20+Pg0KRGF0ZTogRnJpZGF5 IDE1IE5vdmVtYmVyIDIwMTMgMDQ6MzkNClRvOiBDaXNjbyBIZXJ0b2docyA8eWhlcnRvZ2hAY2lz Y28uY29tPG1haWx0bzp5aGVydG9naEBjaXNjby5jb20+PiwgTHVjeSB5b25nIDxsdWN5LnlvbmdA aHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgWHV4aWFvaHUgPHh1eGlh b2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgTWF0dGhldyBCb2Nj aSA8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOm1hdHRoZXcuYm9jY2lA YWxjYXRlbC1sdWNlbnQuY29tPj4sICJudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3Jn PiIgPG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtu dm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4t bnZvMy1hcmNoLTAxLnR4dA0KDQpIaSBZdmVzLA0KU2VlIGlubGluZS4gLSBMYXJyeQ0KDQpGcm9t OiAiWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpIiA8eWhlcnRvZ2hAY2lzY28uY29tPG1haWx0bzp5 aGVydG9naEBjaXNjby5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIE5vdmVtYmVyIDE0LCAyMDEzIDEx OjE1IEFNDQpUbzogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55 b25nQGh1YXdlaS5jb20+PiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1 eGlhb2h1QGh1YXdlaS5jb20+PiwgIkJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KSIgPG1hdHRoZXcu Ym9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVj ZW50LmNvbT4+LCAibnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4iIDxudm8zQGll dGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBm b3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0w MS50eHQNCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBuZWVkIGZvciBhbiBOVkUgdG8gTlZFIGNvbnRy b2wgcGxhbmUuDQoNCkxLPiBZdmVzLCBpbiBzZWN0aW9uIDMuMi41LjIgb2YgZHJhZnQtaGVydG9n aHMtbnZvMy1saXNwLWNvbnRyb2xwbGFuZS11bmlmaWVkLTAwIChuZWFyIHRoZSBib3R0b20gb2Yg cGFnZSAxMSksIGl0IGRlc2NyaWJlcyBhbiBFVFIgc2VuZGluZyBhIFNvbGljaXQgTWFwIFJlcXVl c3QgbWVzc2FnZSB0byBhbiBJVFIgZGlyZWN0bHkuICBHaXZlbiB0aGlzLCB3aHkgZG8geW91IGRp c2FncmVlIHNpbmNlIHlvdXIgb3duIGRyYWZ0IGRlc2NyaWJlcyBhbiBOVkUgc2VuZGluZyBhIGNv bnRyb2wgbWVzc2FnZSB0byBhbm90aGVyIE5WRT8NCg0KIFRoYXQgZG9lc24ndCBtZWFuIHRoYXQg eW91IGNhbid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgZGlzdHJpYnV0ZWQgTlZBIHdpdGgg ZXZlcnkgTlZFLCB3aGljaCBpcyB0aGUgbW9kZWwgdGhhdCBlLmcuIEJHUC9MM1ZQTiBvciBJU0lT L1RSSUxMIHVzZXMuDQoNCll2ZXMNCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2Vp LmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTQgTm92 ZW1iZXIgMjAxMyAxNjo1OQ0KVG86IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0 bzp4dXhpYW9odUBodWF3ZWkuY29tPj4sIE1hdHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzptYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4+ LCAibnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3JnPG1h aWx0bzpudm8zQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRv cHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0K SSBzaGFyZSBteSB2aWV3Lg0KDQpUaGUgY3VycmVudCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMg bW9yZSBmb2N1c2luZyBvbiBOVkUtTlZBIGludGVyZmFjZSBhbmQgYXNzdW1lcyB0aGF0IE5WQSBp cyBhYmxlIHRvIG9idGFpbiBhbGwgVk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlv bqGvcyB0aGF0IGFuIE5WRSBuZWVkcy4gVGhhdCBkb2VzIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhh dCBubyBjb250cm9sIHBsYW5lIHByb3RvY29sIGlzIG5lZWRlZCBiZXR3ZWVuIE5WRXMuIChOVkUt TlZFIGRhdGEgcGxhbmUgcHJvdG9jb2wgaXMgc3RpbGwgbmVlZGVkKS4gIEZyb20gdGhlIGFyY2hp dGVjdHVyZSBwZXJzcGVjdGl2ZSwgaWYgaXQgYWxsb3dzIHRoZSBjb250cm9sIHBsYW5lIHByb3Rv Y29sIGV4aXN0IGJvdGggYmV0d2VlbiBOVkUtTlZBIGFuZCBOVkUtTlZFLCBpdCBtYXkgbGVhZCB2 ZXJ5IGNvbXBsZXggc29sdXRpb24gYW5kIG1hbnkgb3BlcmF0aW9uIGlzc3VlOyBpdCBoYXMgdG8g cmVzb2x2ZSB3aGljaCBpbmZvcm1hdGlvbiBOVkUgc2hvdWxkIHRydXN0IG9yIHVzZSwgaS5lLiBm cm9tIE5WQSBvciBmcm9tIE5WRS4NCg0KV2VhdGhlciB0aGlzIG1lYW5zIGV4Y2x1ZGluZyBUUklM TCBvciBTUEIsIGl0IGlzIGRlYmF0YWJsZS4gVGhlIGN1cnJlbnQgY2hhcnRlciBjbGVhcmx5IHN0 YXRlcyB0aGF0IE5WTzMgdGFyZ2V0cyBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXIgSVAgbmV0 d29yay4gQmV5b25kIHRoaXMgcG9pbnQsIFRSSUxMIGhhcyBkaXJlY3RvcnkgYmFzZWQgc29sdXRp b24sIHdoaWNoIGZpdHMgaW50byBOVkUtTlZBIGFyY2hpdGVjdHVyZS4gIFNQQiBhbHNvIGhhdmUg U1BCLUVWUE4gc29sdXRpb24gdGhhdCBhbHNvIGFsaWducyB3aXRoIE5WRS1OVkEgYXJjaGl0ZWN0 dXJlLg0KDQpJTU86IE5WRS1OVkEgYmFzZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYW5k IE5WRS1OVkUgYmFzZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYXJlIGJvdGggcG9zc2li bGUgZm9yIE5WTzMsIGJ1dCBub3QgdGhlIGNvbWJpbmVkIGFyY2hpdGVjdHVyZS4gQXMgeW91IHNh aWQsIGl0IGlzIHRydWUgdGhhdCBOVkUtTlZFIGJhc2VkIGFyY2hpdGVjdHVyZSBpcyB1c2VmdWwg aW4gc29tZSBzbWFsbCBhcHBsaWNhdGlvbnMuICBTaW5jZSBUUklMTCBhbmQgU0JQIGFscmVhZHkg YWRkcmVzcyBpdCwgTlZPMyBzaG91bGQgb25seSBmb2N1cyBvbiB0aGUgTlZFLU5WQSBiYXNlZCBh cmNoaXRlY3R1cmUuIE9uZSBvZiBOVk8zIGdvYWwgaXMgdGhlIHNjYWxhYmlsaXR5Lg0KDQpMdWN5 DQoNCkZyb206bnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUN ClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAyOjU4IEFNDQpUbzogQm9jY2ksIE1h dHRoZXcgKE1hdHRoZXcpOyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KU3Vi amVjdDogW252bzNdILTwuLQ6IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9y IGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkhpIGFsbCwNCg0KSW4gdGhlIGN1cnJl bnQgYXJjaCBkcmFmdCwgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiBOVkUtTlZFIHByb3RvY29sLiBE b2VzIGl0IG1lYW4gdGhhdCB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXJlY3QgZXhjaGFuZ2Ugb2Yg Vk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIE5WRXM/IElmIHNv LCBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY29udHJvbCBwbGFuZSBtZWNoYW5pc21zIHVzZWQgYnkg VFJJTEwgb3IgU1BCIHdoaWNoIGRlcGVuZCBvbiB0aGUgTlZFLU5WRSBpbnRlcmFjdGlvbiBhcmUg bm90IHN1aXRhYmxlIGZvciBtdWx0aS10ZW5hbnQgZGF0YSBjZW50ZXIgbmV0d29ya3MgYW55bW9y ZSwgbGVhdmluZyBhc2lkZSB3aGV0aGVyIHRoZSB1bmRlcmxheSBpcyBJUCBvciBub3QuDQoNCklN SE8sIHRoZSBOVkUtTlZFIHByb3RvY29sIGlzIHN0aWxsIHVzZWZ1bCBpbiBzb21lIHNtYWxsIGFu ZCBtZWRpdW0gc2l6ZWQgbXVsdGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzLiBBRkFJSywg bW9zdCB0ZW5hbnRzIHdpdGhpbiBwdWJsaWMgY2xvdWQgZGF0YSBjZW50ZXJzIGFyZSBzbWFsbCBh bmQgbWVkaXVtIHNpemVkIGVudGVycHJpc2VzIHdoaWNoIHVzdWFsbHkgZG9uoa90IG5lZWQgYSBs b3Qgb2YgVk1zLiBUaGF0IG1lYW5zIHRoZSBudW1iZXIgb2YgTlZFcyBmb3IgbW9zdCBWTnMgd291 bGQgbm90IGJlIHZlcnkgbGFyZ2UgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgTlZF IGlzIGRlcGxveWVkIGF0IHBoeXNpY2FsIHN3aXRjaGVzLCByYXRoZXIgdGhhbiBoeXBlcnZpc29y cy9zZXJ2ZXJzLiBJbiB0aGlzIGNhc2UsIHRoZSBWTiBtZW1iZXJzaGlwIGNhbiBiZSBkaXNjb3Zl cmVkIHZpYSBJR1AgZmxvb2RpbmcgYW5kIHRoZSBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24g b2YgYSBnaXZlbiBWTiBjb3VsZCBiZSBkaXJlY3RseSBleGNoYW5nZWQgYW1vbmcgTlZFcyBvZiB0 aGF0IFZOLCB3aXRob3V0IGEgbmVlZCBmb3IgYSBkZWRpY2F0ZWQgTlZBLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOm52bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7UJvY2Np LCBNYXR0aGV3IChNYXR0aGV3KQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MIxM8jVIDIxOjU4DQrK1bz+ yMs6bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCtb3zOI6IFtudm8zXSBQb2xs IGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNo LTAxLnR4dA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgdG8gaGVscCB0aGUg Y2hhaXJzIGp1ZGdlIGlmIHRoZXJlIGlzIGNvbnNlbnN1cyAgdG8gYWRvcHQgZHJhZnQtbmFydGVu LW52bzMtYXJjaC0wMS50eHQgYXMgYW4gTlZPMyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQbGVh c2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIG9uIHRoZSBsaXN0IHdpdGggJ3N1cHBvcnQnIG9yICdk byBub3Qgc3VwcG9ydCcuDQoNClBsZWFzZSBhbHNvIHNlbmQgYW55IGNvbW1lbnRzIG9uIHRoZSBk cmFmdCB0byB0aGUgTlZPMyBsaXN0Lg0KDQpQbGVhc2UgY29uc2lkZXIgd2hldGhlciB0aGlzIGRy YWZ0IHRha2VzIHRoZSByaWdodCBiYXNpYyBhcHByb2FjaCwgYW5kIGlzIGEgZ29vZCBiYXNpcyBm b3IgdGhlIHdvcmsgZ29pbmcgZm9yd2FyZCAoYW5kIHBvdGVudGlhbCBmdXR1cmUgcmVjaGFydGVy aW5nKS4gSXQgZG9lcyBub3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgc3RhZ2UuDQoNCkNv aW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUg bGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25k IHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhh cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5 b3UgYXJlIG9uIHRoZSBOVk8zIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu IGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9u bHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNj bG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGlzIHBvbGwgY2xvc2Vz IG9uIEZyaWRheSAyOXRoIE5vdmVtYmVyIDIwMTMuDQoNClJlZ2FyZHMNCg0KTWF0dGhldyBhbmQg QmVuc29uDQoNCg== --_000_CEAB99BE28433yhertoghciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <100C6F31C61ECA44872C171BA8227BD6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Larry,

I guess this is where the abstraction that Xiahou is referring to can = lead to confusion. In LISP the NVA function is mostly logically centr= alised, however the local cache at the xTR's are authoritative as well i.e.= They can be seen as an extension of the NVA function. This is how DDT operates, the xTR's can be part of= the DDT lookup (very similar to a DNS).

So perhaps my question is now: are the NVE and NVA entitities that we = are talking about nodes, or functions within a node?

Based on my understanding it is the latter, hence my interpretation th= at the pure NVE 'function' does not need a control-plane to interact with t= he NVE function on another node, although it could interact with the NVA fu= nction resident on the same node.

Yves

From: "Larry Kreeger (kreeger)= " <kreeger@cisco.com> Date: Friday 15 November 2013 04:39=
To: Cisco Hertoghs <yhertogh@cisco.com>, Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <= ;xuxiaohu@huawei.com>, Matthew Bocci <matt= hew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.or= g>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

Hi Yves,

See inline. - Larry

From: "Yves Hertoghs (yhertogh= )" <yhertogh@cisco.com>= ;
Date: Thursday, November 14, 2013 1= 1:15 AM
To: Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "Bocci, M= atthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I disagree with the need for an NVE to NVE control plane.

LK> Yves, in section 3.2.5.2 of draft-hertoghs-nvo3-lisp-contr= olplane-unified-00 (near the bottom of page 11), it describes an ETR sendin= g a Solicit Map Request message to an ITR directly. Given this, why d= o you disagree since your own draft describes an NVE sending a control message to another NVE?

That doesn't mean that you can't colocate a portion of the distr= ibuted NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/T= RILL uses.

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:= 59
To: Xuxiaohu <xuxiaohu@huawei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.c= om>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I share my view.=

The current architecture document = is more focusing on NVE-NVA interface and assumes that NVA is able to obtai= n all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather this means excluding TRILL= or SPB, it is debatable. The current charter clearly states that NVO3 targ= ets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE= -NVA architecture. SPB also have SPB-EVPN solution that also aligns w= ith NVE-NVA architecture.

IMO: NVE-NVA based control plane a= rchitecture and NVE-NVE based control plane architecture are both possible = for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From:nvo3-bou= nces@ietf.org [mailto:nvo3-bou= nces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for d= raft-narten-nvo3-arch-01.txt

Hi all,

In the current arch draft, there i= s no mention of NVE-NVE protocol. Does it mean that there is no need for di= rect exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mecha= nisms used by TRILL or SPB which depend on the NVE-NVE interaction are not = suitable for multi-tenant data center networks anymore, leaving aside wheth= er the underlay is IP or not.

IMHO, the NVE-NVE protocol is stil= l useful in some small and medium sized multi-tenant data center networks. = AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1= =AFt need a lot of VMs. That means the number of NVEs for most VNs would no= t be very large especially in the case where the NVE is deployed at physica= l switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regards,
Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.= org [mailto:nvo3-bounces@ietf.org= ] =B4= =FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA= 11=D4=C213= =C8=D5 21:58
=CA=D5=BC=FE=C8=CB:= nvo3@ietf.org
=D6=F7=CC=E2: [nvo3= ] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt=

T= his email begins a two week poll to help the chairs judge if there is conse= nsus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working g= roup draft.

P= lease respond to this email on the list with 'support' or 'do not support'.=

P= lease also send any comments on the draft to the NVO3 list.

P= lease consider whether this draft takes the right basic approach, and is a = good basis for the work going forward (and potential future rechartering). = It does not have to be perfect at this stage.

C= oincidentally, 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).

I= f 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.

I= f you are on the NVO3 WG email list but are not listed as an author or cont= ributor, then please explicitly respond only if you are aware of any IPR th= at has not yet been disclosed in conformance with IETF rules.

T= his poll closes on Friday 29th November 2013.

R= egards

M= atthew and Benson

--_000_CEAB99BE28433yhertoghciscocom_-- From lucy.yong@huawei.com Fri Nov 15 08:51:17 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C39621F99B0 for ; Fri, 15 Nov 2013 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS-Dm04QulLf for ; Fri, 15 Nov 2013 08:51:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2E321F9A8C for ; Fri, 15 Nov 2013 08:51:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI49136; Fri, 15 Nov 2013 16:51:01 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 16:49:56 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 16:51:00 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 08:50:50 -0800 From: Lucy yong To: Xuxiaohu , "Yves Hertoghs (yhertogh)" , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WV1DOJ0FXC7z0KRkWrL1VMJlZomALkAgACAOtA= Date: Fri, 15 Nov 2013 16:50:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EE10B@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229962@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.62] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EE10Bdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 16:51:17 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EE10Bdfweml509mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 IElmIHdlIGhhdmUgZm9sbG93aW5nIHRleHQgaW4gdGhlIGZyYW1ld29yaywgaXQgd2lsbCBtYWtl IHRoZSBmcmFtZXdvcmsgYW5kIGFyY2hpdGVjdHVyZSBkb2MgYWxpZ24gd2VsbC4NCg0KDQogICAg ICAgSXQgaXMgcG9zc2libGUgZm9yIE5WRXMgdG8gY29tbXVuaWNhdGUgd2l0aCBhbiBleHRlcm5h bCBOZXR3b3JrDQogICAgICAgVmlydHVhbGl6YXRpb24gQXV0aG9yaXR5IChOVkEpIHRvIG9idGFp biByZWFjaGFiaWxpdHkgYW5kIGZvcndhcmRpbmcNCiAgICAgICBpbmZvcm1hdGlvbi4gSW4gdGhp cyBjYXNlLCBhIHByb3RvY29sIGlzIHVzZWQgYmV0d2VlbiBOVkVzIGFuZA0KICAgICAgIE5WQShz KSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbi4gT3BlbkZsb3cgW09GXSBpcyBvbmUgZXhhbXBsZSBv ZiBzdWNoDQogICAgICAgYSBwcm90b2NvbC4NCg0KDQogICAgICBJdCBpcyBhbHNvIHBvc3NpYmxl IGZvciBOVkEgcGFydGlhbCBvciBlbnRpcmUgbW9kdWxlIGNvLWxvY2F0ZXMgd2l0aCBldmVyeSBO VkUuIFRoaXMgaXMgaG93DQogICAgICAgcm91dGluZyBjb250cm9sIHBsYW5lIG1vZHVsZXMgYXJl IGltcGxlbWVudGVkIGluIHJvdXRlcnMgZm9yIGluc3RhbmNlLg0KDQoNCkx1Y3kNCg0KRnJvbTog WHV4aWFvaHUNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyA3OjA1IFBNDQpUbzog WXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpOyBMdWN5IHlvbmc7IEJvY2NpLCBNYXR0aGV3IChNYXR0 aGV3KTsgbnZvM0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogW252bzNdIFBvbGwgZm9yIFdHIGFk b3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoN ClRoZSBmcmFtZXdvcmsgbWVudGlvbmVkIHR3byBhcHByb2FjaGVzIChzZWUgYmVsb3cpOg0KDQpJ biBvcmRlciB0byBnZXQgcmVhY2hhYmlsaXR5IGluZm9ybWF0aW9uLCBOVkVzIG1heSBleGNoYW5n ZQ0KICAgICAgIGluZm9ybWF0aW9uIGRpcmVjdGx5IGJldHdlZW4gdGhlbXNlbHZlcyB2aWEgYSBw cm90b2NvbC4gSW4gdGhpcw0KDQoNCiAgICBMYXNzZXJyZSwgZXQgYWwuICAgICAgICBFeHBpcmVz IE1heSAxMiwgMjAxNCAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoNCiA8aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1udm8zLWZyYW1ld29yay0wNCNwYWdlLTEwPg0KICAg IEludGVybmV0LURyYWZ0ICBGcmFtZXdvcmsgZm9yIERDIE5ldHdvcmsgVmlydHVhbGl6YXRpb24g ICAgICBOb3ZlbWJlcg0KICAgIDIwMTMNCg0KDQogICAgICAgY2FzZSwgYSBjb250cm9sIHBsYW5l IG1vZHVsZSByZXNpZGVzIGluIGV2ZXJ5IE5WRS4gVGhpcyBpcyBob3cNCiAgICAgICByb3V0aW5n IGNvbnRyb2wgcGxhbmUgbW9kdWxlcyBhcmUgaW1wbGVtZW50ZWQgaW4gcm91dGVycyBmb3INCiAg ICAgICBpbnN0YW5jZS4NCg0KICAgICAgIEl0IGlzIGFsc28gcG9zc2libGUgZm9yIE5WRXMgdG8g Y29tbXVuaWNhdGUgd2l0aCBhbiBleHRlcm5hbCBOZXR3b3JrDQogICAgICAgVmlydHVhbGl6YXRp b24gQXV0aG9yaXR5IChOVkEpIHRvIG9idGFpbiByZWFjaGFiaWxpdHkgYW5kIGZvcndhcmRpbmcN CiAgICAgICBpbmZvcm1hdGlvbi4gSW4gdGhpcyBjYXNlLCBhIHByb3RvY29sIGlzIHVzZWQgYmV0 d2VlbiBOVkVzIGFuZA0KICAgICAgIE5WQShzKSB0byBleGNoYW5nZSBpbmZvcm1hdGlvbi4gT3Bl bkZsb3cgW09GXSBpcyBvbmUgZXhhbXBsZSBvZiBzdWNoDQogICAgICAgYSBwcm90b2NvbC4NCg0K Tm93IHRoZSBhcmNoIGRyYWZ0IG1lbnRpb25lZCBvbmx5IHRoZSBOVkUtTlZBIGludGVyYWN0aW9u IGFwcHJvYWNoLiBEb2VzIGl0IG1lYW4gdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUg ZnJhbWV3b3JrIGRyYWZ0IGlzIHN0YWxlPw0KDQpYaWFvaHUNCg0Kt6K8/sjLOiBudm8zLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpudm8zLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpDQq3osvNyrG85Dog MjAxM8TqMTHUwjE1yNUgMjoxNQ0KytW8/sjLOiBMdWN5IHlvbmc7IFh1eGlhb2h1OyBCb2NjaSwg TWF0dGhldyAoTWF0dGhldyk7IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQrW 98ziOiBSZTogW252bzNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRy YWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkkgZGlzYWdyZWUgd2l0aCB0aGUgbmVlZCBm b3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLiAgVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCB5 b3UgY2FuJ3QgY29sb2NhdGUgYSBwb3J0aW9uIG9mIHRoZSBkaXN0cmlidXRlZCBOVkEgd2l0aCBl dmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUuZy4gQkdQL0wzVlBOIG9yIElTSVMv VFJJTEwgdXNlcy4NCg0KWXZlcw0KDQpGcm9tOiBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBUaHVyc2RheSAxNCBOb3Zl bWJlciAyMDEzIDE2OjU5DQpUbzogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRv Onh1eGlhb2h1QGh1YXdlaS5jb20+PiwgTWF0dGhldyBCb2NjaSA8bWF0dGhldy5ib2NjaUBhbGNh dGVsLWx1Y2VudC5jb208bWFpbHRvOm1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPj4s ICJudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPiIgPG52bzNAaWV0Zi5vcmc8bWFp bHRvOm52bzNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9w dGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpJ IHNoYXJlIG15IHZpZXcuDQoNClRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBpcyBt b3JlIGZvY3VzaW5nIG9uIE5WRS1OVkEgaW50ZXJmYWNlIGFuZCBhc3N1bWVzIHRoYXQgTlZBIGlz IGFibGUgdG8gb2J0YWluIGFsbCBWTiBhbmQvb3IgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9u oa9zIHRoYXQgYW4gTlZFIG5lZWRzLiBUaGF0IGRvZXMgaW1wbGljaXRseSBpbmRpY2F0ZSB0aGF0 IG5vIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgaXMgbmVlZGVkIGJldHdlZW4gTlZFcy4gKE5WRS1O VkUgZGF0YSBwbGFuZSBwcm90b2NvbCBpcyBzdGlsbCBuZWVkZWQpLiAgRnJvbSB0aGUgYXJjaGl0 ZWN0dXJlIHBlcnNwZWN0aXZlLCBpZiBpdCBhbGxvd3MgdGhlIGNvbnRyb2wgcGxhbmUgcHJvdG9j b2wgZXhpc3QgYm90aCBiZXR3ZWVuIE5WRS1OVkEgYW5kIE5WRS1OVkUsIGl0IG1heSBsZWFkIHZl cnkgY29tcGxleCBzb2x1dGlvbiBhbmQgbWFueSBvcGVyYXRpb24gaXNzdWU7IGl0IGhhcyB0byBy ZXNvbHZlIHdoaWNoIGluZm9ybWF0aW9uIE5WRSBzaG91bGQgdHJ1c3Qgb3IgdXNlLCBpLmUuIGZy b20gTlZBIG9yIGZyb20gTlZFLg0KDQpXZWF0aGVyIHRoaXMgbWVhbnMgZXhjbHVkaW5nIFRSSUxM IG9yIFNQQiwgaXQgaXMgZGViYXRhYmxlLiBUaGUgY3VycmVudCBjaGFydGVyIGNsZWFybHkgc3Rh dGVzIHRoYXQgTlZPMyB0YXJnZXRzIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlciBJUCBuZXR3 b3JrLiBCZXlvbmQgdGhpcyBwb2ludCwgVFJJTEwgaGFzIGRpcmVjdG9yeSBiYXNlZCBzb2x1dGlv biwgd2hpY2ggZml0cyBpbnRvIE5WRS1OVkEgYXJjaGl0ZWN0dXJlLiAgU1BCIGFsc28gaGF2ZSBT UEItRVZQTiBzb2x1dGlvbiB0aGF0IGFsc28gYWxpZ25zIHdpdGggTlZFLU5WQSBhcmNoaXRlY3R1 cmUuDQoNCklNTzogTlZFLU5WQSBiYXNlZCBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZSBhbmQg TlZFLU5WRSBiYXNlZCBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZSBhcmUgYm90aCBwb3NzaWJs ZSBmb3IgTlZPMywgYnV0IG5vdCB0aGUgY29tYmluZWQgYXJjaGl0ZWN0dXJlLiBBcyB5b3Ugc2Fp ZCwgaXQgaXMgdHJ1ZSB0aGF0IE5WRS1OVkUgYmFzZWQgYXJjaGl0ZWN0dXJlIGlzIHVzZWZ1bCBp biBzb21lIHNtYWxsIGFwcGxpY2F0aW9ucy4gIFNpbmNlIFRSSUxMIGFuZCBTQlAgYWxyZWFkeSBh ZGRyZXNzIGl0LCBOVk8zIHNob3VsZCBvbmx5IGZvY3VzIG9uIHRoZSBOVkUtTlZBIGJhc2VkIGFy Y2hpdGVjdHVyZS4gT25lIG9mIE5WTzMgZ29hbCBpcyB0aGUgc2NhbGFiaWxpdHkuDQoNCkx1Y3kN Cg0KRnJvbTogbnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUN ClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAyOjU4IEFNDQpUbzogQm9jY2ksIE1h dHRoZXcgKE1hdHRoZXcpOyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KU3Vi amVjdDogW252bzNdILTwuLQ6IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9y IGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkhpIGFsbCwNCg0KSW4gdGhlIGN1cnJl bnQgYXJjaCBkcmFmdCwgdGhlcmUgaXMgbm8gbWVudGlvbiBvZiBOVkUtTlZFIHByb3RvY29sLiBE b2VzIGl0IG1lYW4gdGhhdCB0aGVyZSBpcyBubyBuZWVkIGZvciBkaXJlY3QgZXhjaGFuZ2Ugb2Yg Vk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIE5WRXM/IElmIHNv LCBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY29udHJvbCBwbGFuZSBtZWNoYW5pc21zIHVzZWQgYnkg VFJJTEwgb3IgU1BCIHdoaWNoIGRlcGVuZCBvbiB0aGUgTlZFLU5WRSBpbnRlcmFjdGlvbiBhcmUg bm90IHN1aXRhYmxlIGZvciBtdWx0aS10ZW5hbnQgZGF0YSBjZW50ZXIgbmV0d29ya3MgYW55bW9y ZSwgbGVhdmluZyBhc2lkZSB3aGV0aGVyIHRoZSB1bmRlcmxheSBpcyBJUCBvciBub3QuDQoNCklN SE8sIHRoZSBOVkUtTlZFIHByb3RvY29sIGlzIHN0aWxsIHVzZWZ1bCBpbiBzb21lIHNtYWxsIGFu ZCBtZWRpdW0gc2l6ZWQgbXVsdGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzLiBBRkFJSywg bW9zdCB0ZW5hbnRzIHdpdGhpbiBwdWJsaWMgY2xvdWQgZGF0YSBjZW50ZXJzIGFyZSBzbWFsbCBh bmQgbWVkaXVtIHNpemVkIGVudGVycHJpc2VzIHdoaWNoIHVzdWFsbHkgZG9uoa90IG5lZWQgYSBs b3Qgb2YgVk1zLiBUaGF0IG1lYW5zIHRoZSBudW1iZXIgb2YgTlZFcyBmb3IgbW9zdCBWTnMgd291 bGQgbm90IGJlIHZlcnkgbGFyZ2UgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgTlZF IGlzIGRlcGxveWVkIGF0IHBoeXNpY2FsIHN3aXRjaGVzLCByYXRoZXIgdGhhbiBoeXBlcnZpc29y cy9zZXJ2ZXJzLiBJbiB0aGlzIGNhc2UsIHRoZSBWTiBtZW1iZXJzaGlwIGNhbiBiZSBkaXNjb3Zl cmVkIHZpYSBJR1AgZmxvb2RpbmcgYW5kIHRoZSBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24g b2YgYSBnaXZlbiBWTiBjb3VsZCBiZSBkaXJlY3RseSBleGNoYW5nZWQgYW1vbmcgTlZFcyBvZiB0 aGF0IFZOLCB3aXRob3V0IGEgbmVlZCBmb3IgYSBkZWRpY2F0ZWQgTlZBLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOm52bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7UJvY2Np LCBNYXR0aGV3IChNYXR0aGV3KQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MIxM8jVIDIxOjU4DQrK1bz+ yMs6bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCtb3zOI6IFtudm8zXSBQb2xs IGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNo LTAxLnR4dA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgdG8gaGVscCB0aGUg Y2hhaXJzIGp1ZGdlIGlmIHRoZXJlIGlzIGNvbnNlbnN1cyAgdG8gYWRvcHQgZHJhZnQtbmFydGVu LW52bzMtYXJjaC0wMS50eHQgYXMgYW4gTlZPMyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQbGVh c2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIG9uIHRoZSBsaXN0IHdpdGggJ3N1cHBvcnQnIG9yICdk byBub3Qgc3VwcG9ydCcuDQoNClBsZWFzZSBhbHNvIHNlbmQgYW55IGNvbW1lbnRzIG9uIHRoZSBk cmFmdCB0byB0aGUgTlZPMyBsaXN0Lg0KDQpQbGVhc2UgY29uc2lkZXIgd2hldGhlciB0aGlzIGRy YWZ0IHRha2VzIHRoZSByaWdodCBiYXNpYyBhcHByb2FjaCwgYW5kIGlzIGEgZ29vZCBiYXNpcyBm b3IgdGhlIHdvcmsgZ29pbmcgZm9yd2FyZCAoYW5kIHBvdGVudGlhbCBmdXR1cmUgcmVjaGFydGVy aW5nKS4gSXQgZG9lcyBub3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgc3RhZ2UuDQoNCkNv aW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVu IGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5 NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUg bGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25k IHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZh bnQgSVBSLiBUaGUgZHJhZnQgd2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhh cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5 b3UgYXJlIG9uIHRoZSBOVk8zIFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFu IGF1dGhvciBvciBjb250cmlidXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9u bHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNj bG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGlzIHBvbGwgY2xvc2Vz IG9uIEZyaWRheSAyOXRoIE5vdmVtYmVyIDIwMTMuDQoNClJlZ2FyZHMNCg0KTWF0dGhldyBhbmQg QmVuc29uDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D452EE10Bdfweml509mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

If we have following t= ext in the framework, it will make the framework and architecture doc align= well.



    &nbs= p;  It is possible for NVEs to communicate with an external Netwo= rk

    &nbs= p; Virtualization Authority (NVA) to obtain reachability and forwardi= ng

    &nbs= p; information. In this case, a protocol is used between NVEs and

    &nbs= p; NVA(s) to exchange information. OpenFlow [OF] is one example of su= ch

    &nbs= p; a protocol.

    &nbs= p; It is also possible for NVA partial or entire module co-locates wit= h every NVE. This is how

    &nbs= p; routing control plane modules are implemented in routers for insta= nce.

<= /p>
Lucy
<= /p>

From: Xuxiaohu
Sent: Thursday, November 14, 2013 7:05 PM
To: Yves Hertoghs (yhertogh); Lucy yong; Bocci, Matthew (Matthew); n= vo3@ietf.org
Subject: =B4=F0=B8=B4: [nvo3] Poll for WG adoption= and IPR check for draft-narten-nvo3-arch-01.txt

The framework mentioned t= wo approaches (see below):

<= /p>
In order to get reachability= information, NVEs may exchange

    &nbs= p; information directly between themselves via a protocol. In this





    Lass= erre, et al.        Expires May 12, 2014=             &nb= sp;     [Page 9]



    Inte= rnet-Draft Framework for DC Network Virtualization   &= nbsp; November

    2013=





    &nbs= p;  case, a control plane module resides in every NVE. This is ho= w

    &nbs= p; routing control plane modules are implemented in routers for<= /o:p>

    &nbs= p; instance.



    &nbs= p;  It is also possible for NVEs to communicate with an external = Network

    &nbs= p; Virtualization Authority (NVA) to obtain reachability and forwardi= ng

    &nbs= p; information. In this case, a protocol is used between NVEs and

    &nbs= p; NVA(s) to exchange information. OpenFlow [OF] is one example of su= ch

    &nbs= p; a protocol.

<= /p>
Now the arch draft mentio= ned only the NVE-NVA interaction approach. Does it mean the information con= tained in the framework draft is stale?

<= /p>
Xiaohu<= /p>
<= /p>

=B7=A2=BC=FE=C8=CB: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] =B4=FA=B1=ED Yves Hertogh= s (yhertogh)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA= 11=D4=C215= =C8=D5 2:15
=CA=D5=BC=FE=C8=CB:= Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
=D6=F7=CC=E2: Re: [= nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt<= o:p>

I disagree with the need fo= r an NVE to NVE control plane. That doesn't mean that you can't coloc= ate a portion of the distributed NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

I share my view.

The current architecture = document is more focusing on NVE-NVA interface and assumes that NVA is able= to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane protocol= is needed between NVEs. (NVE-NVE data plane protocol is still needed). &nb= sp;From the architecture perspective, if it allows the control plane protoc= ol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it has to reso= lve which information NVE should trust or use, i.e. from NVA or from NVE.

Weather this means exclud= ing TRILL or SPB, it is debatable. The current charter clearly states that = NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE-NVA ar= chitecture. SPB also have SPB-EVPN solution that also aligns with NVE= -NVA architecture.

IMO: NVE-NVA based contro= l plane architecture and NVE-NVE based control plane architecture are both = possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some sma= ll applications. Since TRILL and SBP already address it, NVO3 should = only focus on the NVE-NVA based architecture. One of NVO3 goal is the scala= bility.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4

=

Hi all,

In the current arch draft= , there is no mention of NVE-NVE protocol. Does it mean that there is no ne= ed for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mechanisms used b= y TRILL or SPB which depend on the NVE-NVE interaction are not suitable for= multi-tenant data center networks anymore, leaving aside whether the under= lay is IP or not.

IMHO, the NVE-NVE protoco= l is still useful in some small and medium sized multi-tenant data center n= etworks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1=AFt need a lot= of VMs. That means the number of NVEs for most VNs would not be very large= especially in the case where the NVE is deployed at physical switches, rat= her than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the address= mapping information of a given VN could be directly exchanged among NVEs o= f that VN, without a need for a dedicated NVA.

Best regards,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org= ] =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11= =D4=C213=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@i= etf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt

=

This email begins a two week poll to help th= e chairs judge if there is consensus to adopt draft-narten-nvo3-= arch-01.txt as an NVO3 working group draft.

=

Please respond to this email on the list wit= h 'support' or 'do not support'.

=

Please also send any comments on the draft t= o the NVO3 list.

=

Please consider whether this draft takes the= right basic approach, and is a good basis for the work going forward (and = potential future rechartering). It does not have to be perfect at this stage.

=

Coincidentally, we are also polling for know= ledge of any IPR that applies to this draft, to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= o:p>

=

If you are listed as a document author or co= ntributor 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 onl= y if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

=

This poll closes on Friday 29th November 201= 3.

=

Regards

=

Matthew and Benson

--_000_2691CE0099834E4A9C5044EEC662BB9D452EE10Bdfweml509mbxchi_-- From lucy.yong@huawei.com Fri Nov 15 09:15:22 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401311E81E6 for ; Fri, 15 Nov 2013 09:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gA-0amVNM8Gt for ; Fri, 15 Nov 2013 09:15:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C71711E81D6 for ; Fri, 15 Nov 2013 09:15:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX98571; Fri, 15 Nov 2013 17:15:14 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 17:14:49 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 17:15:12 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 09:15:01 -0800 From: Lucy yong To: Xuxiaohu , "Yves Hertoghs (yhertogh)" , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WV1DOJ0FXC7z0KRkWrL1VMJlZomCkGAgAB5VEA= Date: Fri, 15 Nov 2013 17:14:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EE13A@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229987@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.62] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EE13Adfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:15:22 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EE13Adfweml509mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WGlhb2h1LA0KDQpbTHVjeV0gcGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuDQoNCreivP7IyzogbnZv My1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86 bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFl2ZXMgSGVydG9naHMgKHloZXJ0b2doKQ0Kt6LL zcqxvOQ6IDIwMTPE6jEx1MIxNcjVIDI6MTUNCsrVvP7IyzogTHVjeSB5b25nOyBYdXhpYW9odTsg Qm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpOyBudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYu b3JnPg0K1vfM4jogUmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNr IGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpJIGRpc2FncmVlIHdpdGggdGhl IG5lZWQgZm9yIGFuIE5WRSB0byBOVkUgY29udHJvbCBwbGFuZS4gIFRoYXQgZG9lc24ndCBtZWFu IHRoYXQgeW91IGNhbid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgZGlzdHJpYnV0ZWQgTlZB IHdpdGggZXZlcnkgTlZFLCB3aGljaCBpcyB0aGUgbW9kZWwgdGhhdCBlLmcuIEJHUC9MM1ZQTiBv ciBJU0lTL1RSSUxMIHVzZXMuDQoNCg0KW1hpYW9odV0gSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGRp c3RyaWJ1dGUgTlZBIGlzIGRlcGxveWVkIGF0IGVhY2ggTlZFLCB3aGF0oa9zIHRoZSBtZWFuaW5n IG9mIGRlZmluaW5nIHRoZSBOVkEtTlZFIHByb3RvY29sPw0KDQpbTHVjeV0gSSBhZ3JlZSB3aGF0 IHlvdSBzYWlkLiBJZiBOVkEgYXJlIGNvLWxvY2F0ZWQgd2l0aCBlYWNoIE5WRSwgdGhlcmUgaXMg bm8gbmVlZCBmb3IgSUVURiB0byB3b3JrIG9uIE5WQS1OVkUgcHJvdG9jb2wuIEJ1dCB0aGF0IGlz IG5vdCB0aGUgYWxsIGNhc2VzLCByaWdodD8gSWYgTlZBIGFuZCBOVkUgYXJlIHNlcGFyYXRlZCwg V2UgbmVlZCBOVkUtTlZBIHByb3RvY29sLCByaWdodC4gVGhpcyBpcyB0aGUgc2FtZSBhcyB3aGVu IE5WRS1UUyBhcmUgY28tbG9jYXRlZCwgbm8gbmVlZCB0byBzcGVjaWZ5IHRoZSBwcm90b2NvbCBp biBiZXR3ZWVuLCBpdCBpcyBhbGwgaW50ZXJuYWwgaW1wbGVtZW50YXRpb24uIEJ1dCBOVk8zIGFs c28gaGF2ZSB0byBzdXBwb3J0IE5WRS1UUyBhcmUgc2VwYXJhdGVkLCB3aGVyZSBoeXBlcnZpc29y LU5WRSBwcm90b2NvbCBpcyBuZWVkZWQuDQoNCiBJTUhPLCBhbG1vc3QgYWxsIHRoZSBkZXNjcmlw dGlvbiB3aXRoaW4gdGhlIGFyY2ggZHJhZnQgZG9lc26hr3QgY29uc2lkZXIgdGhlIGFib3ZlIGNh c2UgYW5kIHRoZXJlZm9yZSBjb25mbGljdCB3aXRoIHRoYXQgY2FzZS4gIElmIHRoZSBXRyBjb25z ZW5zdXMgaXMgdGhhdCB0aGUgYWJvdmUgY2FzZSBpcyB2YWxpZCBhcyB3ZWxsLCBpdCBzaG91bGQg YXQgbGVhc3QgbWVudGlvbiB0aGF0IGNhc2UgZXhwbGljaXRseSBzb21ld2hlcmUgaW4gdGhlIGRy YWZ0IGFsdGhvdWdoIHRoZSB3aG9sZSBkcmFmdCBpcyBmb2N1c2VkICBvbiB0aGUgY2VudHJhbGl6 ZWQgY29udHJvbGxlcihpLmUsIE5WQSktYmFzZWQgYXJjaGl0ZWN0dXJlLg0KDQpbTHVjeV0gSU1P OiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGZvY3VzZXMgb24gdGhlIE5WRSBhbmQgTlZBIHNl cGFyYXRpb24gZnJvbSB0aGUgZnVuY3Rpb25hbCBwZXJzcGVjdGl2ZS4gVGhlcmVmb3JlLCBhIHBy b3RvY29sIGJldHdlZW4gTlZFLU5WQSBpcyBuZWNlc3NhcnkgaW4gdGhlIGNhc2UuIEhvd2V2ZXIs IHRoaXMgc2VwYXJhdGlvbiBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgZGF0YSBwbGFuZSBhbmQgY29u dHJvbCBwbGFuZSBzZXBhcmF0aW9uLCBvciB0aGUgY29udHJvbCBwbGFuZSBzZXBhcmF0aW9uLCBp LmUuIHNvbWUgY29udHJvbCBwbGFuZSBmdW5jdGlvbiBvbiBOVkUsIHNvbWUgb24gTlZBLCB3aGlj aCBjYW4gYmUgdGhlIGNhc2Ugb2YgQkdQIHcvUlIsIG9yIGZ1bGx5IGRpc3RyaWJ1dGVkIE5WQS4g VGh1cyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGFsbG93cyBhbGwgdGhlc2Ugc29sdXRpb25z LiBGb3IgdGhlIGxhc3QgdHdvIGNhc2VzLCBpdCBpcyBvYnZpb3VzbHkgdGhhdCB3ZSBkbyBub3Qg bmVlZCB0byBkZXZlbG9wIGEgbmV3IHByb3RvY29sLCBidXQgbmVlZCB0byBleGFtIGlmIGV4aXN0 aW5nIHByb3RvY29sIGNhbiBmaXQgTlZPMyB3ZWxsLCB3aGVyZSBuZWVkIHRvIGVuaGFuY2UgYW5k IHdoZXJlIG5lZWQgdG8gaW1wbHkuDQoNCg0KDQoNCg0KDQoNCkx1Y3kNCg0KWGlhb2h1DQoNCll2 ZXMNCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55 b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTQgTm92ZW1iZXIgMjAxMyAxNjo1OQ0K VG86IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWku Y29tPj4sIE1hdHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPG1h aWx0bzptYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCAibnZvM0BpZXRmLm9yZzxt YWlsdG86bnZvM0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVj ayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSSBzaGFyZSBteSB2aWV3Lg0K DQpUaGUgY3VycmVudCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgbW9yZSBmb2N1c2luZyBvbiBO VkUtTlZBIGludGVyZmFjZSBhbmQgYXNzdW1lcyB0aGF0IE5WQSBpcyBhYmxlIHRvIG9idGFpbiBh bGwgVk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbqGvcyB0aGF0IGFuIE5WRSBu ZWVkcy4gVGhhdCBkb2VzIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhhdCBubyBjb250cm9sIHBsYW5l IHByb3RvY29sIGlzIG5lZWRlZCBiZXR3ZWVuIE5WRXMuIChOVkUtTlZFIGRhdGEgcGxhbmUgcHJv dG9jb2wgaXMgc3RpbGwgbmVlZGVkKS4gIEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2 ZSwgaWYgaXQgYWxsb3dzIHRoZSBjb250cm9sIHBsYW5lIHByb3RvY29sIGV4aXN0IGJvdGggYmV0 d2VlbiBOVkUtTlZBIGFuZCBOVkUtTlZFLCBpdCBtYXkgbGVhZCB2ZXJ5IGNvbXBsZXggc29sdXRp b24gYW5kIG1hbnkgb3BlcmF0aW9uIGlzc3VlOyBpdCBoYXMgdG8gcmVzb2x2ZSB3aGljaCBpbmZv cm1hdGlvbiBOVkUgc2hvdWxkIHRydXN0IG9yIHVzZSwgaS5lLiBmcm9tIE5WQSBvciBmcm9tIE5W RS4NCg0KV2VhdGhlciB0aGlzIG1lYW5zIGV4Y2x1ZGluZyBUUklMTCBvciBTUEIsIGl0IGlzIGRl YmF0YWJsZS4gVGhlIGN1cnJlbnQgY2hhcnRlciBjbGVhcmx5IHN0YXRlcyB0aGF0IE5WTzMgdGFy Z2V0cyBuZXR3b3JrIHZpcnR1YWxpemF0aW9uIG92ZXIgSVAgbmV0d29yay4gQmV5b25kIHRoaXMg cG9pbnQsIFRSSUxMIGhhcyBkaXJlY3RvcnkgYmFzZWQgc29sdXRpb24sIHdoaWNoIGZpdHMgaW50 byBOVkUtTlZBIGFyY2hpdGVjdHVyZS4gIFNQQiBhbHNvIGhhdmUgU1BCLUVWUE4gc29sdXRpb24g dGhhdCBhbHNvIGFsaWducyB3aXRoIE5WRS1OVkEgYXJjaGl0ZWN0dXJlLg0KDQpJTU86IE5WRS1O VkEgYmFzZWQgY29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYW5kIE5WRS1OVkUgYmFzZWQgY29u dHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYXJlIGJvdGggcG9zc2libGUgZm9yIE5WTzMsIGJ1dCBu b3QgdGhlIGNvbWJpbmVkIGFyY2hpdGVjdHVyZS4gQXMgeW91IHNhaWQsIGl0IGlzIHRydWUgdGhh dCBOVkUtTlZFIGJhc2VkIGFyY2hpdGVjdHVyZSBpcyB1c2VmdWwgaW4gc29tZSBzbWFsbCBhcHBs aWNhdGlvbnMuICBTaW5jZSBUUklMTCBhbmQgU0JQIGFscmVhZHkgYWRkcmVzcyBpdCwgTlZPMyBz aG91bGQgb25seSBmb2N1cyBvbiB0aGUgTlZFLU5WQSBiYXNlZCBhcmNoaXRlY3R1cmUuIE9uZSBv ZiBOVk8zIGdvYWwgaXMgdGhlIHNjYWxhYmlsaXR5Lg0KDQpMdWN5DQoNCkZyb206IG52bzMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52bzMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFh1eGlhb2h1DQpTZW50OiBUaHVyc2RheSwg Tm92ZW1iZXIgMTQsIDIwMTMgMjo1OCBBTQ0KVG86IEJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KTsg bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NClN1YmplY3Q6IFtudm8zXSC08Li0 OiBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZv My1hcmNoLTAxLnR4dA0KDQpIaSBhbGwsDQoNCkluIHRoZSBjdXJyZW50IGFyY2ggZHJhZnQsIHRo ZXJlIGlzIG5vIG1lbnRpb24gb2YgTlZFLU5WRSBwcm90b2NvbC4gRG9lcyBpdCBtZWFuIHRoYXQg dGhlcmUgaXMgbm8gbmVlZCBmb3IgZGlyZWN0IGV4Y2hhbmdlIG9mIFZOIGFuZC9vciBhZGRyZXNz IG1hcHBpbmcgaW5mb3JtYXRpb24gYmV0d2VlbiBOVkVzPyBJZiBzbywgRG9lcyBpdCBtZWFuIHRo YXQgdGhlIGNvbnRyb2wgcGxhbmUgbWVjaGFuaXNtcyB1c2VkIGJ5IFRSSUxMIG9yIFNQQiB3aGlj aCBkZXBlbmQgb24gdGhlIE5WRS1OVkUgaW50ZXJhY3Rpb24gYXJlIG5vdCBzdWl0YWJsZSBmb3Ig bXVsdGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzIGFueW1vcmUsIGxlYXZpbmcgYXNpZGUg d2hldGhlciB0aGUgdW5kZXJsYXkgaXMgSVAgb3Igbm90Lg0KDQpJTUhPLCB0aGUgTlZFLU5WRSBw cm90b2NvbCBpcyBzdGlsbCB1c2VmdWwgaW4gc29tZSBzbWFsbCBhbmQgbWVkaXVtIHNpemVkIG11 bHRpLXRlbmFudCBkYXRhIGNlbnRlciBuZXR3b3Jrcy4gQUZBSUssIG1vc3QgdGVuYW50cyB3aXRo aW4gcHVibGljIGNsb3VkIGRhdGEgY2VudGVycyBhcmUgc21hbGwgYW5kIG1lZGl1bSBzaXplZCBl bnRlcnByaXNlcyB3aGljaCB1c3VhbGx5IGRvbqGvdCBuZWVkIGEgbG90IG9mIFZNcy4gVGhhdCBt ZWFucyB0aGUgbnVtYmVyIG9mIE5WRXMgZm9yIG1vc3QgVk5zIHdvdWxkIG5vdCBiZSB2ZXJ5IGxh cmdlIGVzcGVjaWFsbHkgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIE5WRSBpcyBkZXBsb3llZCBhdCBw aHlzaWNhbCBzd2l0Y2hlcywgcmF0aGVyIHRoYW4gaHlwZXJ2aXNvcnMvc2VydmVycy4gSW4gdGhp cyBjYXNlLCB0aGUgVk4gbWVtYmVyc2hpcCBjYW4gYmUgZGlzY292ZXJlZCB2aWEgSUdQIGZsb29k aW5nIGFuZCB0aGUgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9uIG9mIGEgZ2l2ZW4gVk4gY291 bGQgYmUgZGlyZWN0bHkgZXhjaGFuZ2VkIGFtb25nIE5WRXMgb2YgdGhhdCBWTiwgd2l0aG91dCBh IG5lZWQgZm9yIGEgZGVkaWNhdGVkIE5WQS4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCrei vP7Iyzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddILT6se1Cb2NjaSwgTWF0dGhldyAoTWF0dGhl dykNCreiy83KsbzkOiAyMDEzxOoxMdTCMTPI1SAyMTo1OA0KytW8/sjLOm52bzNAaWV0Zi5vcmc8 bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQrW98ziOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24g YW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KVGhpcyBl bWFpbCBiZWdpbnMgYSB0d28gd2VlayBwb2xsIHRvIGhlbHAgdGhlIGNoYWlycyBqdWRnZSBpZiB0 aGVyZSBpcyBjb25zZW5zdXMgIHRvIGFkb3B0IGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0 IGFzIGFuIE5WTzMgd29ya2luZyBncm91cCBkcmFmdC4NCg0KUGxlYXNlIHJlc3BvbmQgdG8gdGhp cyBlbWFpbCBvbiB0aGUgbGlzdCB3aXRoICdzdXBwb3J0JyBvciAnZG8gbm90IHN1cHBvcnQnLg0K DQpQbGVhc2UgYWxzbyBzZW5kIGFueSBjb21tZW50cyBvbiB0aGUgZHJhZnQgdG8gdGhlIE5WTzMg bGlzdC4NCg0KUGxlYXNlIGNvbnNpZGVyIHdoZXRoZXIgdGhpcyBkcmFmdCB0YWtlcyB0aGUgcmln aHQgYmFzaWMgYXBwcm9hY2gsIGFuZCBpcyBhIGdvb2QgYmFzaXMgZm9yIHRoZSB3b3JrIGdvaW5n IGZvcndhcmQgKGFuZCBwb3RlbnRpYWwgZnV0dXJlIHJlY2hhcnRlcmluZykuIEl0IGRvZXMgbm90 IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHN0YWdlLg0KDQpDb2luY2lkZW50YWxseSwgd2Ug YXJlIGFsc28gcG9sbGluZyBmb3Iga25vd2xlZGdlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRv IHRoaXMgZHJhZnQsIHRvIGVuc3VyZSB0aGF0IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29t cGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFu ZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3Vt ZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIHdo ZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhlIGRyYWZ0 IHdpbGwgbm90IGJlIGFkb3B0ZWQgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBjb250cmlidXRvci4NCg0KSWYgeW91IGFyZSBvbiB0aGUgTlZP MyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJp YnV0b3IsIHRoZW4gcGxlYXNlIGV4cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdh cmUgb2YgYW55IElQUiB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1h bmNlIHdpdGggSUVURiBydWxlcy4NCg0KVGhpcyBwb2xsIGNsb3NlcyBvbiBGcmlkYXkgMjl0aCBO b3ZlbWJlciAyMDEzLg0KDQpSZWdhcmRzDQoNCk1hdHRoZXcgYW5kIEJlbnNvbg0KDQo= --_000_2691CE0099834E4A9C5044EEC662BB9D452EE13Adfweml509mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Xiaohu,

<= /p>
[Lucy] please see i= nline below.
<= /p>

=B7=A2=BC=FE=C8=CB: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] =B4=FA=B1=ED Yves Hertogh= s (yhertogh)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA= 11=D4=C215= =C8=D5 2:15
=CA=D5=BC=FE=C8=CB:= Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
=D6=F7=CC=E2: Re: [= nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt<= o:p>

I disagree with the need fo= r an NVE to NVE control plane. That doesn't mean that you can't coloc= ate a portion of the distributed NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.

<= /p>
[Xiaohu]= In the case where the distribute NVA is deployed at each NVE, what=A1=AFs = the meaning of defining the NVA-NVE protocol?

[L= ucy] I agree what you said. If NVA are co-located with each NVE, there is n= o need for IETF to work on NVA-NVE protocol. But that is not the all cases,= right? If NVA and NVE are separated, We need NVE-NVA protocol, right. This= is the same as when NVE-TS are co-located, no need to specify the protocol= in between, it is all internal implementation. But NVO3 also have to suppo= rt NVE-TS are separated, where hypervisor-NVE protocol is needed.

IMHO, a= lmost all the description within the arch draft doesn=A1=AFt consider the a= bove case and therefore conflict with that case. If the WG consensus = is that the above case is valid as well, it should at least mention that ca= se explicitly somewhere in the draft although the whole draft is focused &n= bsp;on the centralized controller(i.e, NVA)-based architecture.<= /span>

[L= ucy] IMO: the architecture document focuses on the NVE and NVA separation f= rom the functional perspective. Therefore, a protocol between NVE-NVA is ne= cessary in the case. However, this separation can be interpreted as data pl= ane and control plane separation, or the control plane separation, i.e. som= e control plane function on NVE, some on NVA, which can be the case of BGP = w/RR, or fully distributed NVA. Thus the architecture document allows all t= hese solutions. For the last two cases, it is obviously that we do not need= to develop a new protocol, but need to exam if existing protocol can fit N= VO3 well, where need to enhance and where need to imply.<= /i>

Lu= cy

<= /p>
Xiaohu<= /p>

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

I share my view.

The current architecture = document is more focusing on NVE-NVA interface and assumes that NVA is able= to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane protocol= is needed between NVEs. (NVE-NVE data plane protocol is still needed). &nb= sp;From the architecture perspective, if it allows the control plane protoc= ol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it has to reso= lve which information NVE should trust or use, i.e. from NVA or from NVE.

Weather this means exclud= ing TRILL or SPB, it is debatable. The current charter clearly states that = NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE-NVA ar= chitecture. SPB also have SPB-EVPN solution that also aligns with NVE= -NVA architecture.

IMO: NVE-NVA based contro= l plane architecture and NVE-NVE based control plane architecture are both = possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some sma= ll applications. Since TRILL and SBP already address it, NVO3 should = only focus on the NVE-NVA based architecture. One of NVO3 goal is the scala= bility.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4

=

Hi all,

In the current arch draft= , there is no mention of NVE-NVE protocol. Does it mean that there is no ne= ed for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mechanisms used b= y TRILL or SPB which depend on the NVE-NVE interaction are not suitable for= multi-tenant data center networks anymore, leaving aside whether the under= lay is IP or not.

IMHO, the NVE-NVE protoco= l is still useful in some small and medium sized multi-tenant data center n= etworks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1=AFt need a lot= of VMs. That means the number of NVEs for most VNs would not be very large= especially in the case where the NVE is deployed at physical switches, rat= her than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the address= mapping information of a given VN could be directly exchanged among NVEs o= f that VN, without a need for a dedicated NVA.

Best regards,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org= ] =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11= =D4=C213=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@i= etf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt

=

This email begins a two week poll to help th= e chairs judge if there is consensus to adopt draft-narten-nvo3-= arch-01.txt as an NVO3 working group draft.

=

Please respond to this email on the list wit= h 'support' or 'do not support'.

=

Please also send any comments on the draft t= o the NVO3 list.

=

Please consider whether this draft takes the= right basic approach, and is a good basis for the work going forward (and = potential future rechartering). It does not have to be perfect at this stage.

=

Coincidentally, we are also polling for know= ledge of any IPR that applies to this draft, to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= o:p>

=

If you are listed as a document author or co= ntributor 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 onl= y if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

=

This poll closes on Friday 29th November 201= 3.

=

Regards

=

Matthew and Benson

--_000_2691CE0099834E4A9C5044EEC662BB9D452EE13Adfweml509mbxchi_-- From lucy.yong@huawei.com Fri Nov 15 09:17:52 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87BD21F9D7D for ; Fri, 15 Nov 2013 09:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usepNmLH5yjF for ; Fri, 15 Nov 2013 09:17:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D2B2C11E81DF for ; Fri, 15 Nov 2013 09:17:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI50651; Fri, 15 Nov 2013 17:17:09 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 17:16:46 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 17:17:08 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 09:16:56 -0800 From: Lucy yong To: Xuxiaohu , "Yves Hertoghs (yhertogh)" , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WV1DOJ0FXC7z0KRkWrL1VMJlZolCNQggAEEToCAAH0qoA== Date: Fri, 15 Nov 2013 17:16:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EE147@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EDB22@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452EDC88@dfweml509-mbx.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082299A3@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.62] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EE147dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:17:52 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EE147dfweml509mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WGlhb2h1LA0KDQpTb3JyeSwgSSBkb26hr3QgZ2V0IHdoYXQgeW91IHNheSBiZWxvdy4NCg0KTHVj eQ0KDQpZdmVzLA0KDQpGcm9tOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZz4gW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCkNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwg MjAxMyAxMjoxNSBQTQ0KVG86IEx1Y3kgeW9uZzsgWHV4aWFvaHU7IEJvY2NpLCBNYXR0aGV3IChN YXR0aGV3KTsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFy dGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSSBkaXNhZ3JlZSB3aXRoIHRoZSBuZWVkIGZvciBhbiBO VkUgdG8gTlZFIGNvbnRyb2wgcGxhbmUuDQpbTHVjeV0gIGRvIHlvdSB0aGluayB3ZSBuZWVkIE5W RS1OVkUgY29udHJvbCBwbGFuZT8gSSBkb26hr3QgdGhpbmsgdGhpcyBpcyB3aGF0IHlvdSBtZWFu IGZyb20gdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQuDQogVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCB5 b3UgY2FuJ3QgY29sb2NhdGUgYSBwb3J0aW9uIG9mIHRoZSBkaXN0cmlidXRlZCBOVkEgd2l0aCBl dmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUuZy4gQkdQL0wzVlBOIG9yIElTSVMv VFJJTEwgdXNlcy4NCltMdWN5XSBBZ3JlZWQuIE5WQSBjYW4gY29sbG9jYXRlIHcvIE5WRS4gKHBh cnRpYWxseSBvciBlbnRpcmUpLg0KDQpbWGlhb2h1XSBJZiB0aGUgYWJvdmUgYXJndW1lbnQgd2Fz IGNvcnJlY3QsIGRvZXMgaXQgbWVhbiB0aGF0IHdlIGNvdWxkIHNheSB0aGF0IHRoZSBJbnRlcm5l dCBvbmx5IHN1cHBvcnRzIHNvdXJjZSByb3V0aW5nIHNpbmNlIHRoZSBkZXN0aW5hdGlvbi1iYXNl ZCByb3V0aW5nIGlzIGEgc3BlY2lmaWMgY2FzZSBvZiB0aGUgc291cmNlIHJvdXRpbmcgKGkuZS4s IHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIHRoZSBvbmx5IGV4cGxpY2l0bHkgc3BlY2lmaWVk IGhvcCBvZiB0aGUgZXhwbGljaXQgcGF0aCk/ICBJTUhPLCBvdmVyLWFic3RyYWN0IHdpbGwgcmVz dWx0IGluIHVubmVjZXNzYXJ5IGNvbmZ1c2lvbnMuDQoNClhpYW9odQ0KDQoNCkx1Y3kNCg0KWXZl cw0KDQpGcm9tOiBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5Lnlv bmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBUaHVyc2RheSAxNCBOb3ZlbWJlciAyMDEzIDE2OjU5DQpU bzogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5j b20+PiwgTWF0dGhldyBCb2NjaSA8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb208bWFp bHRvOm1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPj4sICJudm8zQGlldGYub3JnPG1h aWx0bzpudm8zQGlldGYub3JnPiIgPG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNr IGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpJIHNoYXJlIG15IHZpZXcuDQoN ClRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBpcyBtb3JlIGZvY3VzaW5nIG9uIE5W RS1OVkEgaW50ZXJmYWNlIGFuZCBhc3N1bWVzIHRoYXQgTlZBIGlzIGFibGUgdG8gb2J0YWluIGFs bCBWTiBhbmQvb3IgYWRkcmVzcyBtYXBwaW5nIGluZm9ybWF0aW9uoa9zIHRoYXQgYW4gTlZFIG5l ZWRzLiBUaGF0IGRvZXMgaW1wbGljaXRseSBpbmRpY2F0ZSB0aGF0IG5vIGNvbnRyb2wgcGxhbmUg cHJvdG9jb2wgaXMgbmVlZGVkIGJldHdlZW4gTlZFcy4gKE5WRS1OVkUgZGF0YSBwbGFuZSBwcm90 b2NvbCBpcyBzdGlsbCBuZWVkZWQpLiAgRnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZl LCBpZiBpdCBhbGxvd3MgdGhlIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgZXhpc3QgYm90aCBiZXR3 ZWVuIE5WRS1OVkEgYW5kIE5WRS1OVkUsIGl0IG1heSBsZWFkIHZlcnkgY29tcGxleCBzb2x1dGlv biBhbmQgbWFueSBvcGVyYXRpb24gaXNzdWU7IGl0IGhhcyB0byByZXNvbHZlIHdoaWNoIGluZm9y bWF0aW9uIE5WRSBzaG91bGQgdHJ1c3Qgb3IgdXNlLCBpLmUuIGZyb20gTlZBIG9yIGZyb20gTlZF Lg0KDQpXZWF0aGVyIHRoaXMgbWVhbnMgZXhjbHVkaW5nIFRSSUxMIG9yIFNQQiwgaXQgaXMgZGVi YXRhYmxlLiBUaGUgY3VycmVudCBjaGFydGVyIGNsZWFybHkgc3RhdGVzIHRoYXQgTlZPMyB0YXJn ZXRzIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3ZlciBJUCBuZXR3b3JrLiBCZXlvbmQgdGhpcyBw b2ludCwgVFJJTEwgaGFzIGRpcmVjdG9yeSBiYXNlZCBzb2x1dGlvbiwgd2hpY2ggZml0cyBpbnRv IE5WRS1OVkEgYXJjaGl0ZWN0dXJlLiAgU1BCIGFsc28gaGF2ZSBTUEItRVZQTiBzb2x1dGlvbiB0 aGF0IGFsc28gYWxpZ25zIHdpdGggTlZFLU5WQSBhcmNoaXRlY3R1cmUuDQoNCklNTzogTlZFLU5W QSBiYXNlZCBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZSBhbmQgTlZFLU5WRSBiYXNlZCBjb250 cm9sIHBsYW5lIGFyY2hpdGVjdHVyZSBhcmUgYm90aCBwb3NzaWJsZSBmb3IgTlZPMywgYnV0IG5v dCB0aGUgY29tYmluZWQgYXJjaGl0ZWN0dXJlLiBBcyB5b3Ugc2FpZCwgaXQgaXMgdHJ1ZSB0aGF0 IE5WRS1OVkUgYmFzZWQgYXJjaGl0ZWN0dXJlIGlzIHVzZWZ1bCBpbiBzb21lIHNtYWxsIGFwcGxp Y2F0aW9ucy4gIFNpbmNlIFRSSUxMIGFuZCBTQlAgYWxyZWFkeSBhZGRyZXNzIGl0LCBOVk8zIHNo b3VsZCBvbmx5IGZvY3VzIG9uIHRoZSBOVkUtTlZBIGJhc2VkIGFyY2hpdGVjdHVyZS4gT25lIG9m IE5WTzMgZ29hbCBpcyB0aGUgc2NhbGFiaWxpdHkuDQoNCkx1Y3kNCg0KRnJvbTogbnZvMy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bnZvMy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFRodXJzZGF5LCBO b3ZlbWJlciAxNCwgMjAxMyAyOjU4IEFNDQpUbzogQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpOyBu dm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KU3ViamVjdDogW252bzNdILTwuLQ6 IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8z LWFyY2gtMDEudHh0DQoNCkhpIGFsbCwNCg0KSW4gdGhlIGN1cnJlbnQgYXJjaCBkcmFmdCwgdGhl cmUgaXMgbm8gbWVudGlvbiBvZiBOVkUtTlZFIHByb3RvY29sLiBEb2VzIGl0IG1lYW4gdGhhdCB0 aGVyZSBpcyBubyBuZWVkIGZvciBkaXJlY3QgZXhjaGFuZ2Ugb2YgVk4gYW5kL29yIGFkZHJlc3Mg bWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIE5WRXM/IElmIHNvLCBEb2VzIGl0IG1lYW4gdGhh dCB0aGUgY29udHJvbCBwbGFuZSBtZWNoYW5pc21zIHVzZWQgYnkgVFJJTEwgb3IgU1BCIHdoaWNo IGRlcGVuZCBvbiB0aGUgTlZFLU5WRSBpbnRlcmFjdGlvbiBhcmUgbm90IHN1aXRhYmxlIGZvciBt dWx0aS10ZW5hbnQgZGF0YSBjZW50ZXIgbmV0d29ya3MgYW55bW9yZSwgbGVhdmluZyBhc2lkZSB3 aGV0aGVyIHRoZSB1bmRlcmxheSBpcyBJUCBvciBub3QuDQoNCklNSE8sIHRoZSBOVkUtTlZFIHBy b3RvY29sIGlzIHN0aWxsIHVzZWZ1bCBpbiBzb21lIHNtYWxsIGFuZCBtZWRpdW0gc2l6ZWQgbXVs dGktdGVuYW50IGRhdGEgY2VudGVyIG5ldHdvcmtzLiBBRkFJSywgbW9zdCB0ZW5hbnRzIHdpdGhp biBwdWJsaWMgY2xvdWQgZGF0YSBjZW50ZXJzIGFyZSBzbWFsbCBhbmQgbWVkaXVtIHNpemVkIGVu dGVycHJpc2VzIHdoaWNoIHVzdWFsbHkgZG9uoa90IG5lZWQgYSBsb3Qgb2YgVk1zLiBUaGF0IG1l YW5zIHRoZSBudW1iZXIgb2YgTlZFcyBmb3IgbW9zdCBWTnMgd291bGQgbm90IGJlIHZlcnkgbGFy Z2UgZXNwZWNpYWxseSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgTlZFIGlzIGRlcGxveWVkIGF0IHBo eXNpY2FsIHN3aXRjaGVzLCByYXRoZXIgdGhhbiBoeXBlcnZpc29ycy9zZXJ2ZXJzLiBJbiB0aGlz IGNhc2UsIHRoZSBWTiBtZW1iZXJzaGlwIGNhbiBiZSBkaXNjb3ZlcmVkIHZpYSBJR1AgZmxvb2Rp bmcgYW5kIHRoZSBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBnaXZlbiBWTiBjb3Vs ZCBiZSBkaXJlY3RseSBleGNoYW5nZWQgYW1vbmcgTlZFcyBvZiB0aGF0IFZOLCB3aXRob3V0IGEg bmVlZCBmb3IgYSBkZWRpY2F0ZWQgTlZBLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8 /sjLOm52bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPiBb bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7UJvY2NpLCBNYXR0aGV3IChNYXR0aGV3 KQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MIxM8jVIDIxOjU4DQrK1bz+yMs6bnZvM0BpZXRmLm9yZzxt YWlsdG86bnZvM0BpZXRmLm9yZz4NCtb3zOI6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBh bmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpUaGlzIGVt YWlsIGJlZ2lucyBhIHR3byB3ZWVrIHBvbGwgdG8gaGVscCB0aGUgY2hhaXJzIGp1ZGdlIGlmIHRo ZXJlIGlzIGNvbnNlbnN1cyAgdG8gYWRvcHQgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQg YXMgYW4gTlZPMyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGlz IGVtYWlsIG9uIHRoZSBsaXN0IHdpdGggJ3N1cHBvcnQnIG9yICdkbyBub3Qgc3VwcG9ydCcuDQoN ClBsZWFzZSBhbHNvIHNlbmQgYW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCB0byB0aGUgTlZPMyBs aXN0Lg0KDQpQbGVhc2UgY29uc2lkZXIgd2hldGhlciB0aGlzIGRyYWZ0IHRha2VzIHRoZSByaWdo dCBiYXNpYyBhcHByb2FjaCwgYW5kIGlzIGEgZ29vZCBiYXNpcyBmb3IgdGhlIHdvcmsgZ29pbmcg Zm9yd2FyZCAoYW5kIHBvdGVudGlhbCBmdXR1cmUgcmVjaGFydGVyaW5nKS4gSXQgZG9lcyBub3Qg aGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgc3RhZ2UuDQoNCkNvaW5jaWRlbnRhbGx5LCB3ZSBh cmUgYWxzbyBwb2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1l bnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgd2hl dGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgZHJhZnQg d2lsbCBub3QgYmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZy b20gZWFjaCBhdXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBOVk8z IFdHIGVtYWlsIGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmli dXRvciwgdGhlbiBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2Fy ZSBvZiBhbnkgSVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFu Y2Ugd2l0aCBJRVRGIHJ1bGVzLg0KDQpUaGlzIHBvbGwgY2xvc2VzIG9uIEZyaWRheSAyOXRoIE5v dmVtYmVyIDIwMTMuDQoNClJlZ2FyZHMNCg0KTWF0dGhldyBhbmQgQmVuc29uDQoNCg== --_000_2691CE0099834E4A9C5044EEC662BB9D452EE147dfweml509mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Xiaohu,=

<= /p>
Sorry, I don=A1=AFt get w= hat you say below.

<= /p>
Lucy

Yves,
<= /p>

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Yves Hertoghs (yhertogh)
Sent: Thursday, November 14, 2013 12:15 PM
To: Lucy yong; Xuxiaohu; Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

I disagree with the need fo= r an NVE to NVE control plane.

[Lucy] do you= think we need NVE-NVE control plane? I don=A1=AFt think this is what you m= ean from the following statement.

That doesn't mean tha= t you can't colocate a portion of the distributed NVA with every NVE, which= is the model that e.g. BGP/L3VPN or ISIS/TRILL uses.

[Lucy] Agreed. NVA = can collocate w/ NVE. (partially or entire).

[Xiaohu] If the above argument was correct= , does it mean that we could say that the Internet only supports source rou= ting since the destination-based routing is a specific case of the source routing (i.e., the destination address is the only expl= icitly specified hop of the explicit path)? IMHO, over-abstract will = result in unnecessary confusions.

<= /p>
Xiaohu<= /p>

Lucy=

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:59
To: Xuxiaohu <xuxiaohu@hua= wei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-nar= ten-nvo3-arch-01.txt

I share my view.

The current architecture = document is more focusing on NVE-NVA interface and assumes that NVA is able= to obtain all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane protocol= is needed between NVEs. (NVE-NVE data plane protocol is still needed). &nb= sp;From the architecture perspective, if it allows the control plane protoc= ol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it has to reso= lve which information NVE should trust or use, i.e. from NVA or from NVE.

Weather this means exclud= ing TRILL or SPB, it is debatable. The current charter clearly states that = NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE-NVA ar= chitecture. SPB also have SPB-EVPN solution that also aligns with NVE= -NVA architecture.

IMO: NVE-NVA based contro= l plane architecture and NVE-NVE based control plane architecture are both = possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some sma= ll applications. Since TRILL and SBP already address it, NVO3 should = only focus on the NVE-NVA based architecture. One of NVO3 goal is the scala= bility.

Lucy

From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4

=

Hi all,

In the current arch draft= , there is no mention of NVE-NVE protocol. Does it mean that there is no ne= ed for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mechanisms used b= y TRILL or SPB which depend on the NVE-NVE interaction are not suitable for= multi-tenant data center networks anymore, leaving aside whether the under= lay is IP or not.

IMHO, the NVE-NVE protoco= l is still useful in some small and medium sized multi-tenant data center n= etworks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1=AFt need a lot= of VMs. That means the number of NVEs for most VNs would not be very large= especially in the case where the NVE is deployed at physical switches, rat= her than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the address= mapping information of a given VN could be directly exchanged among NVEs o= f that VN, without a need for a dedicated NVA.

Best regards,

Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org= ] =B4=FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11= =D4=C213=C8=D5 21:58
=CA=D5=BC=FE=C8=CB:nvo3@i= etf.org
=D6=F7=CC=E2: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt

=

This email begins a two week poll to help th= e chairs judge if there is consensus to adopt draft-narten-nvo3-= arch-01.txt as an NVO3 working group draft.

=

Please respond to this email on the list wit= h 'support' or 'do not support'.

=

Please also send any comments on the draft t= o the NVO3 list.

=

Please consider whether this draft takes the= right basic approach, and is a good basis for the work going forward (and = potential future rechartering). It does not have to be perfect at this stage.

=

Coincidentally, we are also polling for know= ledge of any IPR that applies to this draft, to ensure that IPR has been di= sclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).<= o:p>

=

If you are listed as a document author or co= ntributor 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 onl= y if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

=

This poll closes on Friday 29th November 201= 3.

=

Regards

=

Matthew and Benson

--_000_2691CE0099834E4A9C5044EEC662BB9D452EE147dfweml509mbxchi_-- From kreeger@cisco.com Fri Nov 15 09:38:12 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7703421F991F for ; Fri, 15 Nov 2013 09:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fX3QqfCSOTe for ; Fri, 15 Nov 2013 09:38:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C67A521F8423 for ; Fri, 15 Nov 2013 09:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36936; q=dns/txt; s=iport; t=1384537084; x=1385746684; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=pEezZ///FJy0RdYf1BUtMBtlpfFPruSUZNgFKOulmBs=; b=YgBUgBQv0ImSprygMhEdDMr8zzVijGY77iXW2etmUQb5ZaNM9fk5Orn9 GTkAo1MHPTT1V1sOipcUTcyOCDqpy96rQ8DRvUbBd+ri9BLLXKj01pTKo Fue+ocyP815TbEpzDiwwNtR7+WZErDgtWiRK2+C3VqLWlAvgpQ2BVrVwl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABVbhlKtJXG+/2dsb2JhbABZgkNEOFOCdrw0GIESFnSCJQEBAQQtQwQXAQYCEQECAQEBIQEGBQQwFAMGCAIEARIbh2aTE5tYCJIsjh0RAYEfChcBBoJhgUoDmBCSDYMogXE5 X-IronPort-AV: E=Sophos;i="4.93,709,1378857600"; d="scan'208,217";a="285372622" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2013 17:38:00 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAFHc0mq025139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 17:38:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 11:37:59 -0600 From: "Larry Kreeger (kreeger)" To: "Yves Hertoghs (yhertogh)" , Lucy yong , Xuxiaohu , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4WWA8z4hBe4/7k6wVW8qLGjOQpolc22AgADpKoCAAAEtgA== Date: Fri, 15 Nov 2013 17:37:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.66.75] Content-Type: multipart/alternative; boundary="_000_CEAB9936BFAEEkreegerciscocom_" MIME-Version: 1.0 Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:38:12 -0000 --_000_CEAB9936BFAEEkreegerciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWXZlcywNCg0KSW4gbXkgaW50ZXJwcmV0YXRpb24sIHRoZSBOVkEgaXMgYSBsb2dpY2FsbHkg Y2VudHJhbGl6ZWQgZnVuY3Rpb24sIGFuZCBpZiB0aGF0IGZ1bmN0aW9uIGhhcHBlbnMgdG8gYmUg Y28tcmVzaWRlbnQgb24gdGhlIHNhbWUgZGV2aWNlIGFzIHRoZSBOVkUsIHRoZW4gaXQgaXMgc3Rp bGwgdGhlIE5WQSAobm90IHRoZSBOVkUpLiAgU2VlIG90aGVyIHJlc3BvbnNlcyBiZWxvdy4NCg0K IC0gTGFycnkNCg0KRnJvbTogIll2ZXMgSGVydG9naHMgKHloZXJ0b2doKSIgPHloZXJ0b2doQGNp c2NvLmNvbTxtYWlsdG86eWhlcnRvZ2hAY2lzY28uY29tPj4NCkRhdGU6IEZyaWRheSwgTm92ZW1i ZXIgMTUsIDIwMTMgMTozMyBBTQ0KVG86IExhcnJ5IEtyZWVnZXIgPGtyZWVnZXJAY2lzY28uY29t PG1haWx0bzprcmVlZ2VyQGNpc2NvLmNvbT4+LCBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWku Y29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVh d2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+LCAiQm9jY2ksIE1hdHRoZXcgKE1h dHRoZXcpIiA8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOm1hdHRoZXcu Ym9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPj4sICJudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGll dGYub3JnPiIgPG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1u YXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpMYXJyeSwNCg0KSSBndWVzcyB0aGlzIGlzIHdoZXJl IHRoZSBhYnN0cmFjdGlvbiB0aGF0IFhpYWhvdSBpcyByZWZlcnJpbmcgdG8gY2FuIGxlYWQgdG8g Y29uZnVzaW9uLiAgSW4gTElTUCB0aGUgTlZBIGZ1bmN0aW9uIGlzIG1vc3RseSBsb2dpY2FsbHkg Y2VudHJhbGlzZWQsIGhvd2V2ZXIgdGhlIGxvY2FsIGNhY2hlIGF0IHRoZSB4VFIncyBhcmUgYXV0 aG9yaXRhdGl2ZSBhcyB3ZWxsIGkuZS4gVGhleSBjYW4gYmUgc2VlbiBhcyBhbiBleHRlbnNpb24g b2YgdGhlIE5WQSBmdW5jdGlvbi4NCg0KTEs+IEkgd291bGQgbm90IGNvbnNpZGVyIHRoZSBjYWNo ZXMgaW4gdGhlIE5WRXMgdG8gYmUgcGFydCBvZiB0aGUgTlZBLg0KDQogVGhpcyBpcyBob3cgRERU IG9wZXJhdGVzLCB0aGUgeFRSJ3MgY2FuIGJlIHBhcnQgb2YgdGhlIEREVCBsb29rdXAgKHZlcnkg c2ltaWxhciB0byBhIEROUykuDQoNCkxLPiBJIGFkbWl0LCBJJ3ZlIG5ldmVyIGxvb2tlZCBpbnRv IHRoZSBkZXRhaWxzIG9mIEREVCwgYnV0IEkgd2FzIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQg dGhlIHByb3RvY29sIGJldHdlZW4geFRScyBhbmQgTVMvTVJzIHdhcyBkZWNvdXBsZWQgZnJvbSB3 aGF0ZXZlciBwcm90b2NvbCBNUy9NUnMgdXNlIGJldHdlZW4gdGhlbXNlbHZlcy4gIGUuZy4geW91 IGNvdWxkIHVzZSBCR1AgdHVubmVscywgb3IgRERUIHdpdGhpbiB0aGUgbWFwcGluZyBzeXN0ZW0s IGJ1dCB4VFJzIGFsd2F5cyB1c2UgdGhlIHNhbWUgTElTUCBwcm90b2NvbCB0byB0aGUgTVMvTVIg YW5kIGFyZSBvYmxpdmlvdXMgdG8gaG93IHRoZSBtYXBwaW5nIHN5c3RlbSB3b3JrcyBpbnRlcm5h bGx5IChCR1AgdHVubmVscyBvciBERFQpLg0KDQpTbyBwZXJoYXBzIG15IHF1ZXN0aW9uIGlzIG5v dzogYXJlIHRoZSBOVkUgYW5kIE5WQSBlbnRpdGl0aWVzIHRoYXQgd2UgYXJlIHRhbGtpbmcgYWJv dXQgbm9kZXMsIG9yIGZ1bmN0aW9ucyB3aXRoaW4gYSBub2RlPw0KQmFzZWQgb24gbXkgdW5kZXJz dGFuZGluZyBpdCBpcyB0aGUgbGF0dGVyLCBoZW5jZSBteSBpbnRlcnByZXRhdGlvbiB0aGF0IHRo ZSBwdXJlIE5WRSAnZnVuY3Rpb24nIGRvZXMgbm90IG5lZWQgYSBjb250cm9sLXBsYW5lIHRvIGlu dGVyYWN0IHdpdGggdGhlIE5WRSBmdW5jdGlvbiBvbiBhbm90aGVyIG5vZGUsIGFsdGhvdWdoIGl0 IGNvdWxkIGludGVyYWN0IHdpdGggdGhlIE5WQSBmdW5jdGlvbiByZXNpZGVudCBvbiB0aGUgc2Ft ZSBub2RlLg0KDQpMSz4gSSBzdGlsbCB0aGluayBpdCBpcyB1c2VmdWwgZm9yIE5WRXMgdG8gYmUg YWJsZSB0byBjb21tdW5pY2F0ZSBkaXJlY3RseSB3aXRoIG90aGVyIE5WRXMgaW4gc29tZSBjYXNl cywgd2l0aCB0aGUgbW9zdCB1c2VmdWwgZXhhbXBsZSwgd2hlcmUgYW4gTlZFIGVzc2VudGlhbGx5 IHNlbmRzIHRoZSBlcXVpdmFsZW50IG9mIGEgSG9zdCBVbnJlYWNoYWJsZSBJQ01QIG1lc3NhZ2Ug YmFjayB0byBhIHNvdXJjZSBOVkUgd2hlbiB0aGUgZGVzdGluYXRpb24gVFMgaXMgbm8gbG9uZ2Vy IGNvbm5lY3RlZCB0byB0aGUgZGVjYXBzdWxhdGluZyBOVkUuICBUaGlzIGRvZXNuJ3QgbmVjZXNz YXJpbHkgY29tbXVuaWNhdGUgbWFwcGluZyBpbmZvcm1hdGlvbiBkaXJlY3RseSwgYnV0IGluc3Rl YWQgYSBub3RpZmljYXRpb24gdGhhdCB0aGUgc291cmNlIE5WRSBtYXkgaGF2ZSBhIHN0YWxlIGNh Y2hlLCBvciBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIHNvdXJjZSBOVkUgc2hvdWxkIHVzZSBhbiBh bHRlcm5hdGUgbWFwcGluZyBpZiB0aGV5IGhhdmUgYW5vdGhlciBhdmFpbGFibGUgKHdoaWNoIG1h eSBiZSB1c2VmdWwgZHVyaW5nIGEgVk0gbWlncmF0aW9uIGV2ZW50KS4NCg0KWXZlcw0KDQpGcm9t OiAiTGFycnkgS3JlZWdlciAoa3JlZWdlcikiIDxrcmVlZ2VyQGNpc2NvLmNvbTxtYWlsdG86a3Jl ZWdlckBjaXNjby5jb20+Pg0KRGF0ZTogRnJpZGF5IDE1IE5vdmVtYmVyIDIwMTMgMDQ6MzkNClRv OiBDaXNjbyBIZXJ0b2docyA8eWhlcnRvZ2hAY2lzY28uY29tPG1haWx0bzp5aGVydG9naEBjaXNj by5jb20+PiwgTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25n QGh1YXdlaS5jb20+PiwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlh b2h1QGh1YXdlaS5jb20+PiwgTWF0dGhldyBCb2NjaSA8bWF0dGhldy5ib2NjaUBhbGNhdGVsLWx1 Y2VudC5jb208bWFpbHRvOm1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPj4sICJudm8z QGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPiIgPG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52 bzNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBh bmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpIaSBZdmVz LA0KU2VlIGlubGluZS4gLSBMYXJyeQ0KDQpGcm9tOiAiWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gp IiA8eWhlcnRvZ2hAY2lzY28uY29tPG1haWx0bzp5aGVydG9naEBjaXNjby5jb20+Pg0KRGF0ZTog VGh1cnNkYXksIE5vdmVtYmVyIDE0LCAyMDEzIDExOjE1IEFNDQpUbzogTHVjeSB5b25nIDxsdWN5 LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgWHV4aWFvaHUg PHh1eGlhb2h1QGh1YXdlaS5jb208bWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+PiwgIkJvY2Np LCBNYXR0aGV3IChNYXR0aGV3KSIgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPG1h aWx0bzptYXR0aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCAibnZvM0BpZXRmLm9yZzxt YWlsdG86bnZvM0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVj ayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSSBkaXNhZ3JlZSB3aXRoIHRo ZSBuZWVkIGZvciBhbiBOVkUgdG8gTlZFIGNvbnRyb2wgcGxhbmUuDQoNCkxLPiBZdmVzLCBpbiBz ZWN0aW9uIDMuMi41LjIgb2YgZHJhZnQtaGVydG9naHMtbnZvMy1saXNwLWNvbnRyb2xwbGFuZS11 bmlmaWVkLTAwIChuZWFyIHRoZSBib3R0b20gb2YgcGFnZSAxMSksIGl0IGRlc2NyaWJlcyBhbiBF VFIgc2VuZGluZyBhIFNvbGljaXQgTWFwIFJlcXVlc3QgbWVzc2FnZSB0byBhbiBJVFIgZGlyZWN0 bHkuICBHaXZlbiB0aGlzLCB3aHkgZG8geW91IGRpc2FncmVlIHNpbmNlIHlvdXIgb3duIGRyYWZ0 IGRlc2NyaWJlcyBhbiBOVkUgc2VuZGluZyBhIGNvbnRyb2wgbWVzc2FnZSB0byBhbm90aGVyIE5W RT8NCg0KIFRoYXQgZG9lc24ndCBtZWFuIHRoYXQgeW91IGNhbid0IGNvbG9jYXRlIGEgcG9ydGlv biBvZiB0aGUgZGlzdHJpYnV0ZWQgTlZBIHdpdGggZXZlcnkgTlZFLCB3aGljaCBpcyB0aGUgbW9k ZWwgdGhhdCBlLmcuIEJHUC9MM1ZQTiBvciBJU0lTL1RSSUxMIHVzZXMuDQoNCll2ZXMNCg0KRnJv bTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdl aS5jb20+Pg0KRGF0ZTogVGh1cnNkYXkgMTQgTm92ZW1iZXIgMjAxMyAxNjo1OQ0KVG86IFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4sIE1h dHRoZXcgQm9jY2kgPG1hdHRoZXcuYm9jY2lAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzptYXR0 aGV3LmJvY2NpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCAibnZvM0BpZXRmLm9yZzxtYWlsdG86bnZv M0BpZXRmLm9yZz4iIDxudm8zQGlldGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbbnZvM10gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJh ZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KSSBzaGFyZSBteSB2aWV3Lg0KDQpUaGUgY3Vy cmVudCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgaXMgbW9yZSBmb2N1c2luZyBvbiBOVkUtTlZBIGlu dGVyZmFjZSBhbmQgYXNzdW1lcyB0aGF0IE5WQSBpcyBhYmxlIHRvIG9idGFpbiBhbGwgVk4gYW5k L29yIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbqGvcyB0aGF0IGFuIE5WRSBuZWVkcy4gVGhh dCBkb2VzIGltcGxpY2l0bHkgaW5kaWNhdGUgdGhhdCBubyBjb250cm9sIHBsYW5lIHByb3RvY29s IGlzIG5lZWRlZCBiZXR3ZWVuIE5WRXMuIChOVkUtTlZFIGRhdGEgcGxhbmUgcHJvdG9jb2wgaXMg c3RpbGwgbmVlZGVkKS4gIEZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZSwgaWYgaXQg YWxsb3dzIHRoZSBjb250cm9sIHBsYW5lIHByb3RvY29sIGV4aXN0IGJvdGggYmV0d2VlbiBOVkUt TlZBIGFuZCBOVkUtTlZFLCBpdCBtYXkgbGVhZCB2ZXJ5IGNvbXBsZXggc29sdXRpb24gYW5kIG1h bnkgb3BlcmF0aW9uIGlzc3VlOyBpdCBoYXMgdG8gcmVzb2x2ZSB3aGljaCBpbmZvcm1hdGlvbiBO VkUgc2hvdWxkIHRydXN0IG9yIHVzZSwgaS5lLiBmcm9tIE5WQSBvciBmcm9tIE5WRS4NCg0KV2Vh dGhlciB0aGlzIG1lYW5zIGV4Y2x1ZGluZyBUUklMTCBvciBTUEIsIGl0IGlzIGRlYmF0YWJsZS4g VGhlIGN1cnJlbnQgY2hhcnRlciBjbGVhcmx5IHN0YXRlcyB0aGF0IE5WTzMgdGFyZ2V0cyBuZXR3 b3JrIHZpcnR1YWxpemF0aW9uIG92ZXIgSVAgbmV0d29yay4gQmV5b25kIHRoaXMgcG9pbnQsIFRS SUxMIGhhcyBkaXJlY3RvcnkgYmFzZWQgc29sdXRpb24sIHdoaWNoIGZpdHMgaW50byBOVkUtTlZB IGFyY2hpdGVjdHVyZS4gIFNQQiBhbHNvIGhhdmUgU1BCLUVWUE4gc29sdXRpb24gdGhhdCBhbHNv IGFsaWducyB3aXRoIE5WRS1OVkEgYXJjaGl0ZWN0dXJlLg0KDQpJTU86IE5WRS1OVkEgYmFzZWQg Y29udHJvbCBwbGFuZSBhcmNoaXRlY3R1cmUgYW5kIE5WRS1OVkUgYmFzZWQgY29udHJvbCBwbGFu ZSBhcmNoaXRlY3R1cmUgYXJlIGJvdGggcG9zc2libGUgZm9yIE5WTzMsIGJ1dCBub3QgdGhlIGNv bWJpbmVkIGFyY2hpdGVjdHVyZS4gQXMgeW91IHNhaWQsIGl0IGlzIHRydWUgdGhhdCBOVkUtTlZF IGJhc2VkIGFyY2hpdGVjdHVyZSBpcyB1c2VmdWwgaW4gc29tZSBzbWFsbCBhcHBsaWNhdGlvbnMu ICBTaW5jZSBUUklMTCBhbmQgU0JQIGFscmVhZHkgYWRkcmVzcyBpdCwgTlZPMyBzaG91bGQgb25s eSBmb2N1cyBvbiB0aGUgTlZFLU5WQSBiYXNlZCBhcmNoaXRlY3R1cmUuIE9uZSBvZiBOVk8zIGdv YWwgaXMgdGhlIHNjYWxhYmlsaXR5Lg0KDQpMdWN5DQoNCkZyb206bnZvMy1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bnZvMy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAx NCwgMjAxMyAyOjU4IEFNDQpUbzogQm9jY2ksIE1hdHRoZXcgKE1hdHRoZXcpOyBudm8zQGlldGYu b3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KU3ViamVjdDogW252bzNdILTwuLQ6IFBvbGwgZm9y IFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEu dHh0DQoNCkhpIGFsbCwNCg0KSW4gdGhlIGN1cnJlbnQgYXJjaCBkcmFmdCwgdGhlcmUgaXMgbm8g bWVudGlvbiBvZiBOVkUtTlZFIHByb3RvY29sLiBEb2VzIGl0IG1lYW4gdGhhdCB0aGVyZSBpcyBu byBuZWVkIGZvciBkaXJlY3QgZXhjaGFuZ2Ugb2YgVk4gYW5kL29yIGFkZHJlc3MgbWFwcGluZyBp bmZvcm1hdGlvbiBiZXR3ZWVuIE5WRXM/IElmIHNvLCBEb2VzIGl0IG1lYW4gdGhhdCB0aGUgY29u dHJvbCBwbGFuZSBtZWNoYW5pc21zIHVzZWQgYnkgVFJJTEwgb3IgU1BCIHdoaWNoIGRlcGVuZCBv biB0aGUgTlZFLU5WRSBpbnRlcmFjdGlvbiBhcmUgbm90IHN1aXRhYmxlIGZvciBtdWx0aS10ZW5h bnQgZGF0YSBjZW50ZXIgbmV0d29ya3MgYW55bW9yZSwgbGVhdmluZyBhc2lkZSB3aGV0aGVyIHRo ZSB1bmRlcmxheSBpcyBJUCBvciBub3QuDQoNCklNSE8sIHRoZSBOVkUtTlZFIHByb3RvY29sIGlz IHN0aWxsIHVzZWZ1bCBpbiBzb21lIHNtYWxsIGFuZCBtZWRpdW0gc2l6ZWQgbXVsdGktdGVuYW50 IGRhdGEgY2VudGVyIG5ldHdvcmtzLiBBRkFJSywgbW9zdCB0ZW5hbnRzIHdpdGhpbiBwdWJsaWMg Y2xvdWQgZGF0YSBjZW50ZXJzIGFyZSBzbWFsbCBhbmQgbWVkaXVtIHNpemVkIGVudGVycHJpc2Vz IHdoaWNoIHVzdWFsbHkgZG9uoa90IG5lZWQgYSBsb3Qgb2YgVk1zLiBUaGF0IG1lYW5zIHRoZSBu dW1iZXIgb2YgTlZFcyBmb3IgbW9zdCBWTnMgd291bGQgbm90IGJlIHZlcnkgbGFyZ2UgZXNwZWNp YWxseSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgTlZFIGlzIGRlcGxveWVkIGF0IHBoeXNpY2FsIHN3 aXRjaGVzLCByYXRoZXIgdGhhbiBoeXBlcnZpc29ycy9zZXJ2ZXJzLiBJbiB0aGlzIGNhc2UsIHRo ZSBWTiBtZW1iZXJzaGlwIGNhbiBiZSBkaXNjb3ZlcmVkIHZpYSBJR1AgZmxvb2RpbmcgYW5kIHRo ZSBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24gb2YgYSBnaXZlbiBWTiBjb3VsZCBiZSBkaXJl Y3RseSBleGNoYW5nZWQgYW1vbmcgTlZFcyBvZiB0aGF0IFZOLCB3aXRob3V0IGEgbmVlZCBmb3Ig YSBkZWRpY2F0ZWQgTlZBLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOm52bzMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm52 bzMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7UJvY2NpLCBNYXR0aGV3IChNYXR0aGV3KQ0Kt6LLzcqx vOQ6IDIwMTPE6jEx1MIxM8jVIDIxOjU4DQrK1bz+yMs6bnZvM0BpZXRmLm9yZzxtYWlsdG86bnZv M0BpZXRmLm9yZz4NCtb3zOI6IFtudm8zXSBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBSIGNo ZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpUaGlzIGVtYWlsIGJlZ2lu cyBhIHR3byB3ZWVrIHBvbGwgdG8gaGVscCB0aGUgY2hhaXJzIGp1ZGdlIGlmIHRoZXJlIGlzIGNv bnNlbnN1cyAgdG8gYWRvcHQgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQgYXMgYW4gTlZP MyB3b3JraW5nIGdyb3VwIGRyYWZ0Lg0KDQpQbGVhc2UgcmVzcG9uZCB0byB0aGlzIGVtYWlsIG9u IHRoZSBsaXN0IHdpdGggJ3N1cHBvcnQnIG9yICdkbyBub3Qgc3VwcG9ydCcuDQoNClBsZWFzZSBh bHNvIHNlbmQgYW55IGNvbW1lbnRzIG9uIHRoZSBkcmFmdCB0byB0aGUgTlZPMyBsaXN0Lg0KDQpQ bGVhc2UgY29uc2lkZXIgd2hldGhlciB0aGlzIGRyYWZ0IHRha2VzIHRoZSByaWdodCBiYXNpYyBh cHByb2FjaCwgYW5kIGlzIGEgZ29vZCBiYXNpcyBmb3IgdGhlIHdvcmsgZ29pbmcgZm9yd2FyZCAo YW5kIHBvdGVudGlhbCBmdXR1cmUgcmVjaGFydGVyaW5nKS4gSXQgZG9lcyBub3QgaGF2ZSB0byBi ZSBwZXJmZWN0IGF0IHRoaXMgc3RhZ2UuDQoNCkNvaW5jaWRlbnRhbGx5LCB3ZSBhcmUgYWxzbyBw b2xsaW5nIGZvciBrbm93bGVkZ2Ugb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFm dCwgdG8gZW5zdXJlIHRoYXQgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9y IG1vcmUgZGV0YWlscykuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9y IG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgd2hldGhlciBvciBu b3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGUgZHJhZnQgd2lsbCBub3Qg YmUgYWRvcHRlZCB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBh dXRob3IgYW5kIGNvbnRyaWJ1dG9yLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBOVk8zIFdHIGVtYWls IGxpc3QgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgdGhl biBwbGVhc2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgaGFzIG5vdCB5ZXQgYmVlbiBkaXNjbG9zZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBJ RVRGIHJ1bGVzLg0KDQpUaGlzIHBvbGwgY2xvc2VzIG9uIEZyaWRheSAyOXRoIE5vdmVtYmVyIDIw MTMuDQoNClJlZ2FyZHMNCg0KTWF0dGhldyBhbmQgQmVuc29uDQoNCg== --_000_CEAB9936BFAEEkreegerciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Yves,

In my interpretation, the NVA is a logically centralized function, and= if that function happens to be co-resident on the same device as the NVE, = then it is still the NVA (not the NVE). See other responses below.

- Larry

From: "Yves Hertoghs (yhertogh= )" <yhertogh@cisco.com>= ;
Date: Friday, November 15, 2013 1:3= 3 AM
To: Larry Kreeger <kreeger@cisco.com>, Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

Larry,

I guess this is where the abstraction that Xiahou is referring to can = lead to confusion. In LISP the NVA function is mostly logically centr= alised, however the local cache at the xTR's are authoritative as well i.e.= They can be seen as an extension of the NVA function.

LK> I would not consider the caches in the NVEs to be part of the N= VA.

This is how DDT operates, the xTR's can be part of the DDT looku= p (very similar to a DNS).

LK> I admit, I've never looked into the details of DDT, but I was u= nder the impression that the protocol between xTRs and MS/MRs was decoupled= from whatever protocol MS/MRs use between themselves. e.g. you could= use BGP tunnels, or DDT within the mapping system, but xTRs always use the same LISP protocol to the MS/MR and are ob= livious to how the mapping system works internally (BGP tunnels or DDT).&nb= sp;

So perhaps my question is now: are the NVE and NVA entitities that we = are talking about nodes, or functions within a node?

Based on my understanding it is the latter, hence my interpretation th= at the pure NVE 'function' does not need a control-plane to interact with t= he NVE function on another node, although it could interact with the NVA fu= nction resident on the same node.

LK> I still think it is useful for NVEs to be able to communicate d= irectly with other NVEs in some cases, with the most useful example, where = an NVE essentially sends the equivalent of a Host Unreachable ICMP message = back to a source NVE when the destination TS is no longer connected to the decapsulating NVE. This doesn't nec= essarily communicate mapping information directly, but instead a notificati= on that the source NVE may have a stale cache, or an indication that the so= urce NVE should use an alternate mapping if they have another available (which may be useful during a VM migration = event).

Yves

From: "Larry Kreeger (kreeger)= " <kreeger@cisco.com> Date: Friday 15 November 2013 04:39=
To: Cisco Hertoghs <yhertogh@cisco.com>, Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <= ;xuxiaohu@huawei.com>, Matthew Bocci <matt= hew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.or= g>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

Hi Yves,

See inline. - Larry

From: "Yves Hertoghs (yhertogh= )" <yhertogh@cisco.com>= ;
Date: Thursday, November 14, 2013 1= 1:15 AM
To: Lucy yong <lucy.yong@huawei.com>, Xuxiaohu <xuxiaohu@huawei.com>, "Bocci, M= atthew (Matthew)" <matthew.bocci@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I disagree with the need for an NVE to NVE control plane.

LK> Yves, in section 3.2.5.2 of draft-hertoghs-nvo3-lisp-contr= olplane-unified-00 (near the bottom of page 11), it describes an ETR sendin= g a Solicit Map Request message to an ITR directly. Given this, why d= o you disagree since your own draft describes an NVE sending a control message to another NVE?

That doesn't mean that you can't colocate a portion of the distr= ibuted NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/T= RILL uses.

Yves

From: Lucy yong <lucy.yong@huawei.com>
Date: Thursday 14 November 2013 16:= 59
To: Xuxiaohu <xuxiaohu@huawei.com>, Matthew Bocci <matthew.bocci@alcatel-lucent.c= om>, "nvo3@ietf.org" <nvo3@ietf.org>
Subject: Re: [nvo3] Poll for WG ado= ption and IPR check for draft-narten-nvo3-arch-01.txt

I share my view.=

The current architecture document = is more focusing on NVE-NVA interface and assumes that NVA is able to obtai= n all VN and/or address mapping information=A1=AFs that an NVE needs. That does implicitly indicate that no control plane pro= tocol is needed between NVEs. (NVE-NVE data plane protocol is still needed)= . From the architecture perspective, if it allows the control plane p= rotocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it ha= s to resolve which information NVE should trust or use, i.e. from NVA or fr= om NVE.

Weather this means excluding TRILL= or SPB, it is debatable. The current charter clearly states that NVO3 targ= ets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE= -NVA architecture. SPB also have SPB-EVPN solution that also aligns w= ith NVE-NVA architecture.

IMO: NVE-NVA based control plane a= rchitecture and NVE-NVE based control plane architecture are both possible = for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some = small applications. Since TRILL and SBP already address it, NVO3 shou= ld only focus on the NVE-NVA based architecture. One of NVO3 goal is the sc= alability.

Lucy

From:nvo3-bou= nces@ietf.org [mailto:nvo3-bou= nces@ietf.org] On Behalf Of Xuxiaohu
Sent: Thursday, November 14, 2013 2:58 AM
To: Bocci, Matthew (Matthew); nvo3@= ietf.org
Subject: [nvo3] =B4=F0=B8=B4: Poll for WG adoption and IPR check for d= raft-narten-nvo3-arch-01.txt

Hi all,

In the current arch draft, there i= s no mention of NVE-NVE protocol. Does it mean that there is no need for di= rect exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mecha= nisms used by TRILL or SPB which depend on the NVE-NVE interaction are not = suitable for multi-tenant data center networks anymore, leaving aside wheth= er the underlay is IP or not.

IMHO, the NVE-NVE protocol is stil= l useful in some small and medium sized multi-tenant data center networks. = AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don=A1= =AFt need a lot of VMs. That means the number of NVEs for most VNs would no= t be very large especially in the case where the NVE is deployed at physica= l switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best regards,
Xiaohu

=B7=A2=BC=FE=C8=CB:nvo3-bounces@ietf.= org [mailto:nvo3-bounces@ietf.org= ] =B4= =FA=B1=EDBocci, Matthew (Matthew)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA= 11=D4=C213= =C8=D5 21:58
=CA=D5=BC=FE=C8=CB:= nvo3@ietf.org
=D6=F7=CC=E2: [nvo3= ] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt=

T= his email begins a two week poll to help the chairs judge if there is conse= nsus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working g= roup draft.

P= lease respond to this email on the list with 'support' or 'do not support'.=

P= lease also send any comments on the draft to the NVO3 list.

P= lease consider whether this draft takes the right basic approach, and is a = good basis for the work going forward (and potential future rechartering). = It does not have to be perfect at this stage.

C= oincidentally, 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).

I= f 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.

I= f you are on the NVO3 WG email list but are not listed as an author or cont= ributor, then please explicitly respond only if you are aware of any IPR th= at has not yet been disclosed in conformance with IETF rules.

T= his poll closes on Friday 29th November 2013.

R= egards

M= atthew and Benson

--_000_CEAB9936BFAEEkreegerciscocom_-- From narten@us.ibm.com Fri Nov 15 14:19:41 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EDA21F9EA2 for ; Fri, 15 Nov 2013 14:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.93 X-Spam-Level: X-Spam-Status: No, score=-109.93 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_NO=0.669, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR4kYSv515AG for ; Fri, 15 Nov 2013 14:19:34 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id D59B821F9F19 for ; Fri, 15 Nov 2013 14:19:20 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 15 Nov 2013 15:19:20 -0700 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 15 Nov 2013 15:19:19 -0700 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A991F6E8040 for ; Fri, 15 Nov 2013 17:19:16 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAFMJIDT8782124 for ; Fri, 15 Nov 2013 22:19:18 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAFMJIbp014848 for ; Fri, 15 Nov 2013 17:19:18 -0500 Received: from cichlid.raleigh.ibm.com ([9.57.69.65]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAFMJFrD014664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Nov 2013 17:19:18 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAFMJB1S028844; Fri, 15 Nov 2013 17:19:11 -0500 Message-Id: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> To: "Yves Hertoghs (yhertogh)" In-reply-to: References: Comments: In-reply-to "Yves Hertoghs (yhertogh)" message dated "Thu, 14 Nov 2013 18:23:26 +0000." Date: Fri, 15 Nov 2013 17:19:11 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13111522-9332-0000-0000-0000022B81FF Cc: "nvo3@ietf.org" , Lucy yong Subject: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 22:19:41 -0000 NVO3 does not need an NVE to NVE control protocol. Calling this out explicitly, as it is consistent with the current architecture document. There is no need for an NVE to NVE control protocol, for the purpose of maintaining/populating the mapping tables. There may well be interactions between NVEs, such as setting up tunnels, creating security associations for protecting data plane traffic, or providing error indications (e.g., equivalent of ICMP "TS unreachable" responses). If folk disagree, now would be a good time to have that conversation. "Yves Hertoghs (yhertogh)" writes: > >> I disagree with the need for an NVE to NVE control plane. > > > [Lucy] do you think we need NVE-NVE control plane? I don’t think > > this is what you mean from the following statement. > > No we dont need an NVE to NVE control plane. > > >> That doesn't mean that you can't colocate a portion of the > >> distributed NVA with every NVE, which is the model that > >> e.g. BGP/L3VPN or ISIS/TRILL uses. > > > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). > > And as a result there is only a need for a control plane between the > NVE function and the NVA function. Thomas From kreeger@cisco.com Fri Nov 15 14:54:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE9E11E821E for ; Fri, 15 Nov 2013 14:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.676 X-Spam-Level: X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=3.923, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNsXGdWuhLLL for ; Fri, 15 Nov 2013 14:54:46 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D211E8218 for ; Fri, 15 Nov 2013 14:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1384556072; x=1385765672; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Gdhubg3vTydHcjhEHzmuKiiwPZI3XqQRN6DLVSUtz3g=; b=Y6UVa3jNRXeq+H5LBVFOXj88dCHRSKB/65bhplPFf2wnpGKC0wV5QTaF 3vTJyJvEk9UnaaKeA2NnRDssl5DZaS4useeQugE47sGAss5VUd8Z5o44d 2FuRZlJE9sYUSThoI/SYgyCEtd2Ms5vcgih2brDAKSqq7uTI3CwN1teZA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAC+lhlKtJXHB/2dsb2JhbABZgweBC4J2vDYYgRIWdIIsIxFFEgEGAhIIAh8HAgQwFQIOAgQBDQWIAZMrm16SMoEpjg0zB4JrgUYDmBCSDYFqgT6CKg X-IronPort-AV: E=Sophos;i="4.93,710,1378857600"; d="scan'208";a="285563224" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2013 22:54:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAFMsNex032470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 22:54:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 16:54:23 -0600 From: "Larry Kreeger (kreeger)" To: Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4lWgw7u292JBWUquLPzBlJ+t0w== Date: Fri, 15 Nov 2013 22:54:22 +0000 Message-ID: In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 22:54:51 -0000 SGkgVGhvbWFzLA0KDQpJIGFncmVlIHdpdGggeW91IGFib3V0IHRoZSB0eXBlcyBvZiBOVkUgdG8g TlZFIGludGVyYWN0aW9ucywgYnV0IGlmIHRoaXMNCmlzbid0IGNhbGxlZCBhIGNvbnRyb2wgcHJv dG9jb2wsIHdoYXQgZG8gd2UgY2FsbCBpdD8gIERvIHdlIG5lZWQNCnJlcXVpcmVtZW50cyBmb3Ig aXQ/DQoNClRoYW5rcywgTGFycnkNCg0KT24gMTEvMTUvMTMgMjoxOSBQTSwgIlRob21hcyBOYXJ0 ZW4iIDxuYXJ0ZW5AdXMuaWJtLmNvbT4gd3JvdGU6DQoNCj5OVk8zIGRvZXMgbm90IG5lZWQgYW4g TlZFIHRvIE5WRSBjb250cm9sIHByb3RvY29sLg0KPg0KPkNhbGxpbmcgdGhpcyBvdXQgZXhwbGlj aXRseSwgYXMgaXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50DQo+YXJjaGl0ZWN0dXJl IGRvY3VtZW50LiBUaGVyZSBpcyBubyBuZWVkIGZvciBhbiBOVkUgdG8gTlZFIGNvbnRyb2wNCj5w cm90b2NvbCwgZm9yIHRoZSBwdXJwb3NlIG9mIG1haW50YWluaW5nL3BvcHVsYXRpbmcgdGhlIG1h cHBpbmcNCj50YWJsZXMuIFRoZXJlIG1heSB3ZWxsIGJlIGludGVyYWN0aW9ucyBiZXR3ZWVuIE5W RXMsIHN1Y2ggYXMgc2V0dGluZw0KPnVwIHR1bm5lbHMsIGNyZWF0aW5nIHNlY3VyaXR5IGFzc29j aWF0aW9ucyBmb3IgcHJvdGVjdGluZyBkYXRhIHBsYW5lDQo+dHJhZmZpYywgb3IgcHJvdmlkaW5n IGVycm9yIGluZGljYXRpb25zIChlLmcuLCBlcXVpdmFsZW50IG9mIElDTVAgIlRTDQo+dW5yZWFj aGFibGUiIHJlc3BvbnNlcykuDQo+DQo+SWYgZm9sayBkaXNhZ3JlZSwgbm93IHdvdWxkIGJlIGEg Z29vZCB0aW1lIHRvIGhhdmUgdGhhdCBjb252ZXJzYXRpb24uDQo+DQo+Ill2ZXMgSGVydG9naHMg KHloZXJ0b2doKSIgPHloZXJ0b2doQGNpc2NvLmNvbT4gd3JpdGVzOg0KPiANCj4+ID4+IEkgZGlz YWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPj4g DQo+PiA+IFtMdWN5XSBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZFIGNvbnRyb2wgcGxhbmU/ IEkgZG9uw6LigqzihKJ0IHRoaW5rDQo+PiA+ICB0aGlzIGlzIHdoYXQgeW91IG1lYW4gZnJvbSB0 aGUgZm9sbG93aW5nIHN0YXRlbWVudC4NCj4+IA0KPj4gTm8gd2UgZG9udCBuZWVkIGFuIE5WRSB0 byBOVkUgY29udHJvbCBwbGFuZS4NCj4+IA0KPj4gPj4gVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCB5 b3UgY2FuJ3QgY29sb2NhdGUgYSBwb3J0aW9uIG9mIHRoZQ0KPj4gPj4gZGlzdHJpYnV0ZWQgTlZB IHdpdGggZXZlcnkgTlZFLCB3aGljaCBpcyB0aGUgbW9kZWwgdGhhdA0KPj4gPj4gZS5nLiBCR1Av TDNWUE4gb3IgSVNJUy9UUklMTCB1c2VzLg0KPj4gDQo+PiA+IFtMdWN5XSBBZ3JlZWQuIE5WQSBj YW4gY29sbG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBvciBlbnRpcmUpLg0KPj4gDQo+PiBBbmQg YXMgYSByZXN1bHQgdGhlcmUgaXMgb25seSBhIG5lZWQgZm9yIGEgY29udHJvbCBwbGFuZSBiZXR3 ZWVuIHRoZQ0KPj4gTlZFIGZ1bmN0aW9uIGFuZCB0aGUgTlZBIGZ1bmN0aW9uLg0KPg0KPlRob21h cw0KPg0KDQo= From lucy.yong@huawei.com Fri Nov 15 15:07:37 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFD321F9F19 for ; Fri, 15 Nov 2013 15:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=2.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iagdvHKdeJI0 for ; Fri, 15 Nov 2013 15:07:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0447811E8128 for ; Fri, 15 Nov 2013 15:07:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI65599; Fri, 15 Nov 2013 23:07:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 23:06:19 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 23:07:23 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 15:07:19 -0800 From: Lucy yong To: "Larry Kreeger (kreeger)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4lWuGe1a3Zf9lEujXGHMkAfpTpom6a4w Date: Fri, 15 Nov 2013 23:07:18 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EE3F5@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 23:07:37 -0000 SSBndWVzcywgc29tZSBvZiB0aGVtIGJlbG9uZyB0byBPQU0uIG90aGVycz8NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExhcnJ5IEtyZWVnZXIgKGtyZWVnZXIpIFttYWlsdG86 a3JlZWdlckBjaXNjby5jb21dIA0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNSwgMjAxMyA0OjU0 IFBNDQpUbzogVGhvbWFzIE5hcnRlbjsgWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpDQpDYzogbnZv M0BpZXRmLm9yZzsgTHVjeSB5b25nDQpTdWJqZWN0OiBSZTogW252bzNdIE5vIG5lZWQgZm9yIE5W RS1OVkUgY29udHJvbCBwbGFuZSBbd2FzIFJlOiBQb2xsIGZvciBXRyBhZG9wdGlvbiBhbmQgSVBS IGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KDQpIaSBUaG9tYXMsDQoN CkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIHR5cGVzIG9mIE5WRSB0byBOVkUgaW50ZXJhY3Rp b25zLCBidXQgaWYgdGhpcyBpc24ndCBjYWxsZWQgYSBjb250cm9sIHByb3RvY29sLCB3aGF0IGRv IHdlIGNhbGwgaXQ/ICBEbyB3ZSBuZWVkIHJlcXVpcmVtZW50cyBmb3IgaXQ/DQoNClRoYW5rcywg TGFycnkNCg0KT24gMTEvMTUvMTMgMjoxOSBQTSwgIlRob21hcyBOYXJ0ZW4iIDxuYXJ0ZW5AdXMu aWJtLmNvbT4gd3JvdGU6DQoNCj5OVk8zIGRvZXMgbm90IG5lZWQgYW4gTlZFIHRvIE5WRSBjb250 cm9sIHByb3RvY29sLg0KPg0KPkNhbGxpbmcgdGhpcyBvdXQgZXhwbGljaXRseSwgYXMgaXQgaXMg Y29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50IA0KPmFyY2hpdGVjdHVyZSBkb2N1bWVudC4gVGhl cmUgaXMgbm8gbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIA0KPnByb3RvY29sLCBmb3Ig dGhlIHB1cnBvc2Ugb2YgbWFpbnRhaW5pbmcvcG9wdWxhdGluZyB0aGUgbWFwcGluZyB0YWJsZXMu IA0KPlRoZXJlIG1heSB3ZWxsIGJlIGludGVyYWN0aW9ucyBiZXR3ZWVuIE5WRXMsIHN1Y2ggYXMg c2V0dGluZyB1cCANCj50dW5uZWxzLCBjcmVhdGluZyBzZWN1cml0eSBhc3NvY2lhdGlvbnMgZm9y IHByb3RlY3RpbmcgZGF0YSBwbGFuZSANCj50cmFmZmljLCBvciBwcm92aWRpbmcgZXJyb3IgaW5k aWNhdGlvbnMgKGUuZy4sIGVxdWl2YWxlbnQgb2YgSUNNUCAiVFMgDQo+dW5yZWFjaGFibGUiIHJl c3BvbnNlcykuDQo+DQo+SWYgZm9sayBkaXNhZ3JlZSwgbm93IHdvdWxkIGJlIGEgZ29vZCB0aW1l IHRvIGhhdmUgdGhhdCBjb252ZXJzYXRpb24uDQo+DQo+Ill2ZXMgSGVydG9naHMgKHloZXJ0b2do KSIgPHloZXJ0b2doQGNpc2NvLmNvbT4gd3JpdGVzOg0KPiANCj4+ID4+IEkgZGlzYWdyZWUgd2l0 aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPj4gDQo+PiA+IFtM dWN5XSBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZFIGNvbnRyb2wgcGxhbmU/IEkgZG9uw6Li gqzihKJ0IHRoaW5rICANCj4+ID4gdGhpcyBpcyB3aGF0IHlvdSBtZWFuIGZyb20gdGhlIGZvbGxv d2luZyBzdGF0ZW1lbnQuDQo+PiANCj4+IE5vIHdlIGRvbnQgbmVlZCBhbiBOVkUgdG8gTlZFIGNv bnRyb2wgcGxhbmUuDQo+PiANCj4+ID4+IFRoYXQgZG9lc24ndCBtZWFuIHRoYXQgeW91IGNhbid0 IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgDQo+PiA+PiBkaXN0cmlidXRlZCBOVkEgd2l0aCBl dmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUuZy4gDQo+PiA+PiBCR1AvTDNWUE4g b3IgSVNJUy9UUklMTCB1c2VzLg0KPj4gDQo+PiA+IFtMdWN5XSBBZ3JlZWQuIE5WQSBjYW4gY29s bG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBvciBlbnRpcmUpLg0KPj4gDQo+PiBBbmQgYXMgYSBy ZXN1bHQgdGhlcmUgaXMgb25seSBhIG5lZWQgZm9yIGEgY29udHJvbCBwbGFuZSBiZXR3ZWVuIHRo ZSANCj4+IE5WRSBmdW5jdGlvbiBhbmQgdGhlIE5WQSBmdW5jdGlvbi4NCj4NCj5UaG9tYXMNCj4N Cg0K From farinacci@gmail.com Fri Nov 15 15:41:06 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7712E11E816B for ; Fri, 15 Nov 2013 15:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8L56XQdNFX8 for ; Fri, 15 Nov 2013 15:41:05 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 93BEF11E815B for ; Fri, 15 Nov 2013 15:41:05 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id v10so4097027pde.11 for ; Fri, 15 Nov 2013 15:41:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=edTvyE3t8402hZllDEPhYGTM/ihtqubXrqbkcogzKVE=; b=HskiF3YlEUh+OZ5VbxFSu1BipcNRzAMvL/DNyrVh2Ma7VkVpOR76UPGF+017YeyNGG Bw1NAABVsTaX3ovnDgtXL5e+O8OC4mP0NTojsfvEIDuWdVocbZBkVQdgjBxNN6axs2zN USRRC5Ukp9Dik8aqCV9a23HfJuIv1TPAb63+5BSdF6RNzk4L2WPjXwWOtnlko+jYcyZA eBoisWuEUH4LvZdw6zVOW72izfJfy3XPAVgYdGGMk3Ux/7AGqK2WTJ3qCwMBNkarNV5+ lGFYiUJW19FXxXIFgSmZ5+C4alMrWhCBZKeTwQl8DHrQvcbCH7C7riQgDpYx86UU65lP 3j1Q== X-Received: by 10.68.218.68 with SMTP id pe4mr1594788pbc.181.1384558865210; Fri, 15 Nov 2013 15:41:05 -0800 (PST) Received: from [192.168.2.158] (ppp-71-139-160-1.dsl.snfc21.pacbell.net. [71.139.160.1]) by mx.google.com with ESMTPSA id ha10sm7004559pbd.17.2013.11.15.15.41.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 15:41:04 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Date: Fri, 15 Nov 2013 15:40:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: "nvo3@ietf.org" , Lucy Yong , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 23:41:06 -0000 > NVO3 does not need an NVE to NVE control protocol. How about so an NVE knows a path to another NVE is up? Because if it is = not, it could choose another NVE that supports the end-host. > Calling this out explicitly, as it is consistent with the current > architecture document. There is no need for an NVE to NVE control > protocol, for the purpose of maintaining/populating the mapping > tables. There may well be interactions between NVEs, such as setting > up tunnels, creating security associations for protecting data plane > traffic, or providing error indications (e.g., equivalent of ICMP "TS > unreachable" responses). Then don't worry about naming semantics. Let's just agree that NVEs need = to talk to each other, other than just encapsulating to each other. > If folk disagree, now would be a good time to have that conversation. I know you may not be suggesting using ICMP unreachables or the = equivalent, but remember they just tell you when something "goes = unreachable". They don't tell you when something has become reachable = (not just become reachable but in a timely fashion), so you'll need some = NVE-to-NVE interaction. Dino >=20 > "Yves Hertoghs (yhertogh)" writes: >=20 >>>> I disagree with the need for an NVE to NVE control plane. >>=20 >>> [Lucy] do you think we need NVE-NVE control plane? I don=92t think >>> this is what you mean from the following statement. >>=20 >> No we dont need an NVE to NVE control plane. >>=20 >>>> That doesn't mean that you can't colocate a portion of the >>>> distributed NVA with every NVE, which is the model that >>>> e.g. BGP/L3VPN or ISIS/TRILL uses. >>=20 >>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>=20 >> And as a result there is only a need for a control plane between the >> NVE function and the NVA function. >=20 > Thomas >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From sbarkai@gmail.com Fri Nov 15 15:41:25 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7A11E816B for ; Fri, 15 Nov 2013 15:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRS6XCfWKfrn for ; Fri, 15 Nov 2013 15:41:24 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A888B11E8122 for ; Fri, 15 Nov 2013 15:41:24 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id va2so4672343obc.34 for ; Fri, 15 Nov 2013 15:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=r1v8Z/BXBhKVWvq4VRoBcmzAVAsfACdi5UqIun+0K9I=; b=RnpYWS5X8ha0EOGJDW79aE92OZ9SJUNR38T/khL76++troFuQMzlr4oWzrGRuhCVaJ iaq3l37MGUwWc05Gv2n9ax7dIdMQDoVGZ2YFGhvmzX8hbgGXpHGzxzSl0/kjIAMV/crV c4p+Zsf3upeYKqa65VMPILIn1lysvxIVZOkMl9H/MePvPhgf7/qsQhXOXWcc2zYwunWc 0SaHXnlyVuZDPUihe6mXi7Y2J1jGFPdOI2ywh6uLRiW0kQhT4wypeIW3/g2oPBQhdqJt e0dmwyh0mq+kdGDWxvmn5gFKmfQvYjINKD5/4fkvwJ1F9utqWg7lECTdVz/hEuJiCWbg kNaA== X-Received: by 10.60.76.72 with SMTP id i8mr9255546oew.11.1384558884205; Fri, 15 Nov 2013 15:41:24 -0800 (PST) Received: from [192.168.1.73] (108-214-96-27.lightspeed.sntcca.sbcglobal.net. [108.214.96.27]) by mx.google.com with ESMTPSA id nw5sm6835200obc.9.2013.11.15.15.41.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 15:41:23 -0800 (PST) References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <74503F7B-11DE-4A00-A0BA-DC93205B35EB@gmail.com> X-Mailer: iPad Mail (11B511) From: Sharon Date: Fri, 15 Nov 2013 15:41:22 -0800 To: Thomas Narten Cc: "nvo3@ietf.org" , Lucy yong , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 23:41:25 -0000 100% agree. There is however a real risk of a control signaling ("NVOi") creeping in, Wrecking some the distributed-emergent elegance & resilience of the spec, and creating long lived states and dependencies which are sizeof(mesh). It always comes up at some point. So you should probably prepare for it. This prep can be in the form of optional overlay OAM or Echo spec. This is be used to measure RTT and such IFF peer NVEs choose to. Per each Echo option that will come up, and guarantee to be many, there should be a simple litmus test which is - can it be mapped. Only if not, then it should be considered. --szb > On Nov 15, 2013, at 14:19, Thomas Narten wrote: >=20 > NVO3 does not need an NVE to NVE control protocol. >=20 > Calling this out explicitly, as it is consistent with the current > architecture document. There is no need for an NVE to NVE control > protocol, for the purpose of maintaining/populating the mapping > tables. There may well be interactions between NVEs, such as setting > up tunnels, creating security associations for protecting data plane > traffic, or providing error indications (e.g., equivalent of ICMP "TS > unreachable" responses). >=20 > If folk disagree, now would be a good time to have that conversation. >=20 > "Yves Hertoghs (yhertogh)" writes: >=20 >>>> I disagree with the need for an NVE to NVE control plane. >>=20 >>> [Lucy] do you think we need NVE-NVE control plane? I don=E2=80=99t think= >>> this is what you mean from the following statement. >>=20 >> No we dont need an NVE to NVE control plane. >>=20 >>>> That doesn't mean that you can't colocate a portion of the >>>> distributed NVA with every NVE, which is the model that >>>> e.g. BGP/L3VPN or ISIS/TRILL uses. >>=20 >>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>=20 >> And as a result there is only a need for a control plane between the >> NVE function and the NVA function. >=20 > Thomas >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From linda.dunbar@huawei.com Fri Nov 15 15:57:09 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A50511E8137 for ; Fri, 15 Nov 2013 15:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjNKe2VE-GHn for ; Fri, 15 Nov 2013 15:57:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9144811E810D for ; Fri, 15 Nov 2013 15:56:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXY15175; Fri, 15 Nov 2013 23:56:47 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 23:55:42 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 23:56:47 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 15:56:38 -0800 From: Linda Dunbar To: Dino Farinacci , Thomas Narten Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4lDNtN/KKDNFHUaN5nYsugEixponeXwA//98S3A= Date: Fri, 15 Nov 2013 23:56:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> In-Reply-To: <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.255] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 23:57:09 -0000 Dino,=20 Are you talking about one TS connected to two different NVEs? Then, there are much other issues, such as will you allow multiple uplinks = to NVEs being active, do traffic between "a" to "b" have to be symmetric? E= tc. many of them being discussed in TRILL.=20 Linda > -----Original Message----- > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of > Dino Farinacci > Sent: Friday, November 15, 2013 5:40 PM > To: Thomas Narten > Cc: nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) > Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for > WG adoption and IPR check for draft-narten-nvo3-arch-01.txt >=20 > > NVO3 does not need an NVE to NVE control protocol. >=20 > How about so an NVE knows a path to another NVE is up? Because if it is > not, it could choose another NVE that supports the end-host. >=20 > > Calling this out explicitly, as it is consistent with the current > > architecture document. There is no need for an NVE to NVE control > > protocol, for the purpose of maintaining/populating the mapping > > tables. There may well be interactions between NVEs, such as setting > > up tunnels, creating security associations for protecting data plane > > traffic, or providing error indications (e.g., equivalent of ICMP "TS > > unreachable" responses). >=20 > Then don't worry about naming semantics. Let's just agree that NVEs > need to talk to each other, other than just encapsulating to each other. >=20 > > If folk disagree, now would be a good time to have that conversation. >=20 > I know you may not be suggesting using ICMP unreachables or the > equivalent, but remember they just tell you when something "goes > unreachable". They don't tell you when something has become reachable > (not just become reachable but in a timely fashion), so you'll need > some NVE-to-NVE interaction. >=20 > Dino >=20 > > > > "Yves Hertoghs (yhertogh)" writes: > > > >>>> I disagree with the need for an NVE to NVE control plane. > >> > >>> [Lucy] do you think we need NVE-NVE control plane? I don't think > >>> this is what you mean from the following statement. > >> > >> No we dont need an NVE to NVE control plane. > >> > >>>> That doesn't mean that you can't colocate a portion of the > >>>> distributed NVA with every NVE, which is the model that > >>>> e.g. BGP/L3VPN or ISIS/TRILL uses. > >> > >>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). > >> > >> And as a result there is only a need for a control plane between the > >> NVE function and the NVA function. > > > > Thomas > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From farinacci@gmail.com Fri Nov 15 16:07:57 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525CA11E810D for ; Fri, 15 Nov 2013 16:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdgc+IJWIehB for ; Fri, 15 Nov 2013 16:07:56 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B685D11E814C for ; Fri, 15 Nov 2013 16:07:32 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id y10so4093141pdj.5 for ; Fri, 15 Nov 2013 16:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LIyyIMRUG5aV/SOh2wcOB6XraS8GzKHSseMx2lz6cvw=; b=gBcefPW7qWnPYOt/HM6a36uvyODn63o8gOZt8NeEfik/hgYk/fLzGPgsxouEdaZo97 Up6p9hr1Wz7d4oXvtlZTF5Z5ZL/uds0uh8aeEFZEB0eiUH/vblXES4cBS8QiRMTZ9iFZ mJvarY8wakE0K0Qs3xQepGsFTF2Qj7mnC3s5S/t8hzXldAD/5lt7msh6XjgTZ/lTnhWz B8OcLDm2wNPXnm+QhuF6Jy0MKkVUwpHrCrJMEnKKytjBJCVqyPF2pa2T9wkhgxs9P41r VmHTwngOHXyuENwZ05IghDs3auGZkXBzZdcXTmz/9bL1G4h2qT7Xmc0kbD/+jH9FUAWD DtMQ== X-Received: by 10.68.14.200 with SMTP id r8mr9075324pbc.52.1384560451015; Fri, 15 Nov 2013 16:07:31 -0800 (PST) Received: from [192.168.2.158] (ppp-71-139-160-1.dsl.snfc21.pacbell.net. [71.139.160.1]) by mx.google.com with ESMTPSA id fk4sm7985015pab.23.2013.11.15.16.07.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 16:07:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> Date: Fri, 15 Nov 2013 16:07:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy Yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 00:07:57 -0000 > Dino,=20 >=20 > Are you talking about one TS connected to two different NVEs? No, I was talking about any NVE talking to any other NVE, regardless of = the number of TSes attached to it. > Then, there are much other issues, such as will you allow multiple = uplinks to NVEs being active, do traffic between "a" to "b" have to be = symmetric? Etc. many of them being discussed in TRILL.=20 ;-) Dino >=20 >=20 > Linda >=20 >> -----Original Message----- >> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf = Of >> Dino Farinacci >> Sent: Friday, November 15, 2013 5:40 PM >> To: Thomas Narten >> Cc: nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) >> Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll = for >> WG adoption and IPR check for draft-narten-nvo3-arch-01.txt >>=20 >>> NVO3 does not need an NVE to NVE control protocol. >>=20 >> How about so an NVE knows a path to another NVE is up? Because if it = is >> not, it could choose another NVE that supports the end-host. >>=20 >>> Calling this out explicitly, as it is consistent with the current >>> architecture document. There is no need for an NVE to NVE control >>> protocol, for the purpose of maintaining/populating the mapping >>> tables. There may well be interactions between NVEs, such as setting >>> up tunnels, creating security associations for protecting data plane >>> traffic, or providing error indications (e.g., equivalent of ICMP = "TS >>> unreachable" responses). >>=20 >> Then don't worry about naming semantics. Let's just agree that NVEs >> need to talk to each other, other than just encapsulating to each = other. >>=20 >>> If folk disagree, now would be a good time to have that = conversation. >>=20 >> I know you may not be suggesting using ICMP unreachables or the >> equivalent, but remember they just tell you when something "goes >> unreachable". They don't tell you when something has become reachable >> (not just become reachable but in a timely fashion), so you'll need >> some NVE-to-NVE interaction. >>=20 >> Dino >>=20 >>>=20 >>> "Yves Hertoghs (yhertogh)" writes: >>>=20 >>>>>> I disagree with the need for an NVE to NVE control plane. >>>>=20 >>>>> [Lucy] do you think we need NVE-NVE control plane? I don't think >>>>> this is what you mean from the following statement. >>>>=20 >>>> No we dont need an NVE to NVE control plane. >>>>=20 >>>>>> That doesn't mean that you can't colocate a portion of the >>>>>> distributed NVA with every NVE, which is the model that >>>>>> e.g. BGP/L3VPN or ISIS/TRILL uses. >>>>=20 >>>>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>>>=20 >>>> And as a result there is only a need for a control plane between = the >>>> NVE function and the NVA function. >>>=20 >>> Thomas >>>=20 >>> _______________________________________________ >>> nvo3 mailing list >>> nvo3@ietf.org >>> https://www.ietf.org/mailman/listinfo/nvo3 >>=20 >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 From linda.dunbar@huawei.com Fri Nov 15 16:14:55 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817AB11E8146 for ; Fri, 15 Nov 2013 16:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxbU8XAQQwzn for ; Fri, 15 Nov 2013 16:14:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA06211E8135 for ; Fri, 15 Nov 2013 16:14:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI68102; Sat, 16 Nov 2013 00:14:50 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 Nov 2013 00:13:45 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 Nov 2013 00:14:49 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 16:14:39 -0800 From: Linda Dunbar To: Dino Farinacci Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4l/lCVTxk5T9oUuEim8Jy4teAJom+/Wg Date: Sat, 16 Nov 2013 00:14:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.255] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 00:14:55 -0000 > > Dino, > > > > Are you talking about one TS connected to two different NVEs? >=20 > No, I was talking about any NVE talking to any other NVE, regardless of > the number of TSes attached to it. Aren't NVEs the end hosts to the underlay network? It is the underlay netwo= rk's responsibility to forward (encapsulated) packets to other NVEs. If the= destination NVEs don't exist, those packets go to black hole.=20 Linda >=20 > > > >> -----Original Message----- > >> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf > Of > >> Dino Farinacci > >> Sent: Friday, November 15, 2013 5:40 PM > >> To: Thomas Narten > >> Cc: nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) > >> Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll > for > >> WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > >> > >>> NVO3 does not need an NVE to NVE control protocol. > >> > >> How about so an NVE knows a path to another NVE is up? Because if it > is > >> not, it could choose another NVE that supports the end-host. > >> > >>> Calling this out explicitly, as it is consistent with the current > >>> architecture document. There is no need for an NVE to NVE control > >>> protocol, for the purpose of maintaining/populating the mapping > >>> tables. There may well be interactions between NVEs, such as > setting > >>> up tunnels, creating security associations for protecting data > plane > >>> traffic, or providing error indications (e.g., equivalent of ICMP > "TS > >>> unreachable" responses). > >> > >> Then don't worry about naming semantics. Let's just agree that NVEs > >> need to talk to each other, other than just encapsulating to each > other. > >> > >>> If folk disagree, now would be a good time to have that > conversation. > >> > >> I know you may not be suggesting using ICMP unreachables or the > >> equivalent, but remember they just tell you when something "goes > >> unreachable". They don't tell you when something has become > reachable > >> (not just become reachable but in a timely fashion), so you'll need > >> some NVE-to-NVE interaction. > >> > >> Dino > >> > >>> > >>> "Yves Hertoghs (yhertogh)" writes: > >>> > >>>>>> I disagree with the need for an NVE to NVE control plane. > >>>> > >>>>> [Lucy] do you think we need NVE-NVE control plane? I don't think > >>>>> this is what you mean from the following statement. > >>>> > >>>> No we dont need an NVE to NVE control plane. > >>>> > >>>>>> That doesn't mean that you can't colocate a portion of the > >>>>>> distributed NVA with every NVE, which is the model that > >>>>>> e.g. BGP/L3VPN or ISIS/TRILL uses. > >>>> > >>>>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). > >>>> > >>>> And as a result there is only a need for a control plane between > the > >>>> NVE function and the NVA function. > >>> > >>> Thomas > >>> > >>> _______________________________________________ > >>> nvo3 mailing list > >>> nvo3@ietf.org > >>> https://www.ietf.org/mailman/listinfo/nvo3 > >> > >> _______________________________________________ > >> nvo3 mailing list > >> nvo3@ietf.org > >> https://www.ietf.org/mailman/listinfo/nvo3 From florin@nuagenetworks.net Fri Nov 15 16:21:35 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11411E810D for ; Fri, 15 Nov 2013 16:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WworsfCRZEpo for ; Fri, 15 Nov 2013 16:21:29 -0800 (PST) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by ietfa.amsl.com (Postfix) with ESMTP id 8062C11E815C for ; Fri, 15 Nov 2013 16:21:29 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id hi5so3135689wib.2 for ; Fri, 15 Nov 2013 16:21:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=C6M3kekS9DBE8PVG3i9wPqBEcaqFeqRtHsZW3SECpxw=; b=ChlLrhfnKl+JpqyOE4lwmDFTiQfxlCv4Honk+9rdDeQ3CjFEHY/2eQH4JOz+aMDJwm UCvhksZHexQiy7jE/tHV7aIKccsgxC+0vl2+ZrCs8tUwgUvrkEXUQuqhmrRF+9d7vyCk 2Cy0jd4HklgLs7DtMX8UN/HKr8M4iip4q8G9DJ5Nzuu48IQn79XjL85x0c0jHS9RSMZd BGxIFjKMFQen/yMdGxdqLMuCa6KXJOgwbY47sP+noKHyxiP3AoUDqNXwJC9mr4eC7pvg xYTzhZjogs8YaSfYxe330o9KizXeYKya21L1crpGgNfB2zG7vpk7XsBnBZM3gd+WLwfD PV9A== X-Gm-Message-State: ALoCoQkPyGwobRAakvUfxFrNnM+P5CtEYSt9IP6oZtp2rs8wIfJH11Bsp/wZkQ2OhaNI5KfFUjHB X-Received: by 10.180.198.79 with SMTP id ja15mr9004040wic.36.1384561288693; Fri, 15 Nov 2013 16:21:28 -0800 (PST) Received: from [135.227.220.163] (63-233-76-254.dia.static.qwest.net. [63.233.76.254]) by mx.google.com with ESMTPSA id i8sm193414wiy.6.2013.11.15.16.21.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 15 Nov 2013 16:21:28 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.0.121105 Date: Fri, 15 Nov 2013 16:21:18 -0800 From: Florin Balus To: Thomas Narten , "Yves Hertoghs (yhertogh)" Message-ID: Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 00:21:35 -0000 Not sure I understand what you are asking. Do you really mean to say there is no need for a control plane protocol period in between NVEs? Or are you stating there is no need for an additional control plane protocol? The existing one(s) would cut it. On 11/15/13, 2:19 PM, "Thomas Narten" wrote: >NVO3 does not need an NVE to NVE control protocol. > >Calling this out explicitly, as it is consistent with the current >architecture document. There is no need for an NVE to NVE control >protocol, for the purpose of maintaining/populating the mapping >tables. There may well be interactions between NVEs, such as setting >up tunnels, creating security associations for protecting data plane >traffic, or providing error indications (e.g., equivalent of ICMP "TS >unreachable" responses). > >If folk disagree, now would be a good time to have that conversation. > >"Yves Hertoghs (yhertogh)" writes: >=20 >> >> I disagree with the need for an NVE to NVE control plane. >>=20 >> > [Lucy] do you think we need NVE-NVE control plane? I don=E2=80=99t think >> > this is what you mean from the following statement. >>=20 >> No we dont need an NVE to NVE control plane. >>=20 >> >> That doesn't mean that you can't colocate a portion of the >> >> distributed NVA with every NVE, which is the model that >> >> e.g. BGP/L3VPN or ISIS/TRILL uses. >>=20 >> > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>=20 >> And as a result there is only a need for a control plane between the >> NVE function and the NVA function. > >Thomas > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Fri Nov 15 16:22:26 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066C911E810D for ; Fri, 15 Nov 2013 16:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=1.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbudzfJRwJWW for ; Fri, 15 Nov 2013 16:22:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8F11E8125 for ; Fri, 15 Nov 2013 16:22:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXY16092; Sat, 16 Nov 2013 00:22:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 Nov 2013 00:21:02 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 16 Nov 2013 00:22:06 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 16:21:57 -0800 From: Lucy yong To: Linda Dunbar , Dino Farinacci Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4l/j6qYOzIFtSUub9qGm1+HIz5ongwqA//97y9A= Date: Sat, 16 Nov 2013 00:21:56 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EE480@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 00:22:26 -0000 Tunnel EPs have OAM tools to monitor each other.=20 Lucy -----Original Message----- From: Linda Dunbar=20 Sent: Friday, November 15, 2013 6:15 PM To: Dino Farinacci Cc: Thomas Narten; nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) Subject: RE: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt > > Dino, > > > > Are you talking about one TS connected to two different NVEs? >=20 > No, I was talking about any NVE talking to any other NVE, regardless=20 > of the number of TSes attached to it. Aren't NVEs the end hosts to the underlay network? It is the underlay netwo= rk's responsibility to forward (encapsulated) packets to other NVEs. If the= destination NVEs don't exist, those packets go to black hole.=20 Linda >=20 > > > >> -----Original Message----- > >> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On=20 > >> Behalf > Of > >> Dino Farinacci > >> Sent: Friday, November 15, 2013 5:40 PM > >> To: Thomas Narten > >> Cc: nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) > >> Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll > for > >> WG adoption and IPR check for draft-narten-nvo3-arch-01.txt > >> > >>> NVO3 does not need an NVE to NVE control protocol. > >> > >> How about so an NVE knows a path to another NVE is up? Because if=20 > >> it > is > >> not, it could choose another NVE that supports the end-host. > >> > >>> Calling this out explicitly, as it is consistent with the current=20 > >>> architecture document. There is no need for an NVE to NVE control=20 > >>> protocol, for the purpose of maintaining/populating the mapping=20 > >>> tables. There may well be interactions between NVEs, such as > setting > >>> up tunnels, creating security associations for protecting data > plane > >>> traffic, or providing error indications (e.g., equivalent of ICMP > "TS > >>> unreachable" responses). > >> > >> Then don't worry about naming semantics. Let's just agree that NVEs=20 > >> need to talk to each other, other than just encapsulating to each > other. > >> > >>> If folk disagree, now would be a good time to have that > conversation. > >> > >> I know you may not be suggesting using ICMP unreachables or the=20 > >> equivalent, but remember they just tell you when something "goes=20 > >> unreachable". They don't tell you when something has become > reachable > >> (not just become reachable but in a timely fashion), so you'll need=20 > >> some NVE-to-NVE interaction. > >> > >> Dino > >> > >>> > >>> "Yves Hertoghs (yhertogh)" writes: > >>> > >>>>>> I disagree with the need for an NVE to NVE control plane. > >>>> > >>>>> [Lucy] do you think we need NVE-NVE control plane? I don't think=20 > >>>>> this is what you mean from the following statement. > >>>> > >>>> No we dont need an NVE to NVE control plane. > >>>> > >>>>>> That doesn't mean that you can't colocate a portion of the=20 > >>>>>> distributed NVA with every NVE, which is the model that e.g.=20 > >>>>>> BGP/L3VPN or ISIS/TRILL uses. > >>>> > >>>>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). > >>>> > >>>> And as a result there is only a need for a control plane between > the > >>>> NVE function and the NVA function. > >>> > >>> Thomas > >>> > >>> _______________________________________________ > >>> nvo3 mailing list > >>> nvo3@ietf.org > >>> https://www.ietf.org/mailman/listinfo/nvo3 > >> > >> _______________________________________________ > >> nvo3 mailing list > >> nvo3@ietf.org > >> https://www.ietf.org/mailman/listinfo/nvo3 From farinacci@gmail.com Fri Nov 15 16:22:29 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4851111E815B for ; Fri, 15 Nov 2013 16:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlu8OKxbRu4O for ; Fri, 15 Nov 2013 16:22:28 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45B11E815A for ; Fri, 15 Nov 2013 16:22:28 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id jt11so4317759pbb.28 for ; Fri, 15 Nov 2013 16:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zgyYzahijbSgVJ9hEd2eSsEb1MuwPi+Ii7+Baf8fEa0=; b=Pd10wYdgute53904JAgeDbDhvxXAeJ0Liz34i6qOUegoZ8j8vtCKNB4XryDSTFd+xs hsrRIaSM56jgswuwhqfmT6Qg55AFudgQ4KLAMC9SZF+wHX0R/jw3zejHRfE+zsDRLukF Q2DQ5kIaN/6AvW+Uacv06eD4yqCphhFIzsXCLQ8ythAqDhPqDCt3lfLevGpGvpCbXKwc 7vcLaXwkCEYRY7CM/aBqJojJrBLxi0mcC10HIti9Hn7shsyRTT2GD9jh10tutCGKqIla i+v8dJKnH5v5KFeXkgSQRIjdJXe59/8Vf4vux1+X6Dv47S4Dg/aUq16OvmWPNPrHHyxS fmOw== X-Received: by 10.66.221.199 with SMTP id qg7mr9427188pac.13.1384561348155; Fri, 15 Nov 2013 16:22:28 -0800 (PST) Received: from [192.168.2.158] (ppp-71-139-160-1.dsl.snfc21.pacbell.net. [71.139.160.1]) by mx.google.com with ESMTPSA id ye1sm8049457pab.19.2013.11.15.16.22.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 16:22:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> Date: Fri, 15 Nov 2013 16:22:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy Yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 00:22:29 -0000 >>> Dino, >>>=20 >>> Are you talking about one TS connected to two different NVEs? >>=20 >> No, I was talking about any NVE talking to any other NVE, regardless = of >> the number of TSes attached to it. >=20 > Aren't NVEs the end hosts to the underlay network? It is the underlay = network's responsibility to forward=20 Don't go there and confuse matters. > (encapsulated) packets to other NVEs. If the destination NVEs don't = exist, those packets go to black hole.=20 Yes, it is. But a NVE could be unreachable and if the encapsulating NVE = has a choice to select another NVE to encapsulate to, it should. This = makes the architecture more robust. Dino >=20 > Linda >=20 >=20 >>=20 >>>=20 >>>> -----Original Message----- >>>> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On = Behalf >> Of >>>> Dino Farinacci >>>> Sent: Friday, November 15, 2013 5:40 PM >>>> To: Thomas Narten >>>> Cc: nvo3@ietf.org; Lucy yong; Yves Hertoghs (yhertogh) >>>> Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll >> for >>>> WG adoption and IPR check for draft-narten-nvo3-arch-01.txt >>>>=20 >>>>> NVO3 does not need an NVE to NVE control protocol. >>>>=20 >>>> How about so an NVE knows a path to another NVE is up? Because if = it >> is >>>> not, it could choose another NVE that supports the end-host. >>>>=20 >>>>> Calling this out explicitly, as it is consistent with the current >>>>> architecture document. There is no need for an NVE to NVE control >>>>> protocol, for the purpose of maintaining/populating the mapping >>>>> tables. There may well be interactions between NVEs, such as >> setting >>>>> up tunnels, creating security associations for protecting data >> plane >>>>> traffic, or providing error indications (e.g., equivalent of ICMP >> "TS >>>>> unreachable" responses). >>>>=20 >>>> Then don't worry about naming semantics. Let's just agree that NVEs >>>> need to talk to each other, other than just encapsulating to each >> other. >>>>=20 >>>>> If folk disagree, now would be a good time to have that >> conversation. >>>>=20 >>>> I know you may not be suggesting using ICMP unreachables or the >>>> equivalent, but remember they just tell you when something "goes >>>> unreachable". They don't tell you when something has become >> reachable >>>> (not just become reachable but in a timely fashion), so you'll need >>>> some NVE-to-NVE interaction. >>>>=20 >>>> Dino >>>>=20 >>>>>=20 >>>>> "Yves Hertoghs (yhertogh)" writes: >>>>>=20 >>>>>>>> I disagree with the need for an NVE to NVE control plane. >>>>>>=20 >>>>>>> [Lucy] do you think we need NVE-NVE control plane? I don't think >>>>>>> this is what you mean from the following statement. >>>>>>=20 >>>>>> No we dont need an NVE to NVE control plane. >>>>>>=20 >>>>>>>> That doesn't mean that you can't colocate a portion of the >>>>>>>> distributed NVA with every NVE, which is the model that >>>>>>>> e.g. BGP/L3VPN or ISIS/TRILL uses. >>>>>>=20 >>>>>>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>>>>>=20 >>>>>> And as a result there is only a need for a control plane between >> the >>>>>> NVE function and the NVA function. >>>>>=20 >>>>> Thomas >>>>>=20 >>>>> _______________________________________________ >>>>> nvo3 mailing list >>>>> nvo3@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>=20 >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nvo3 >=20 From lizho.jin@gmail.com Sun Nov 17 21:23:10 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C311E8536 for ; Sun, 17 Nov 2013 21:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szMtRJojoHII for ; Sun, 17 Nov 2013 21:23:09 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id CAB3811E8534 for ; Sun, 17 Nov 2013 21:23:09 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id lj1so416104pab.15 for ; Sun, 17 Nov 2013 21:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=WmBeDc8xPn8ReFnMqk+XkzBFb2taoUriOMhzIfA1y6Q=; b=pODaB0PX2nu7sPwNIdzBzkicbW0JoWUV3wjcGF+LCtDLHMo19gFCSG0HasHuaNjaVl ZxIbC0Ck/Ni+X3kQdCWuzQXaeUNG0kfS03St1kTBL+l/8Ly6MTtb/I/0zNAauTPxZ+x3 rTk/NlK+wrFUoJwVIPWbE6KYrWZ1pFN5HSMa0L3aPMkInzus4cM6iPxH7F1HKRpT3zof 8xYC9fHcLDoZybY3Ed2ctum5sSSqeRqKPhyo4ogM7dZgHVDJT9cX4Vgiq52N85gj9tU4 n4pj1qzr1V0wFV+AL3OlEnCiYGzaHBW85PheIPLpFm8yf+UTxZQ8g33XqWey778Oju5T Uwbw== X-Received: by 10.67.3.34 with SMTP id bt2mr19623233pad.3.1384752189627; Sun, 17 Nov 2013 21:23:09 -0800 (PST) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id rx4sm23412848pab.13.2013.11.17.21.23.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 17 Nov 2013 21:23:07 -0800 (PST) From: "Lizhong Jin" To: "'Thomas Narten'" , "'Yves Hertoghs $yhertogh$'" Date: Mon, 18 Nov 2013 13:23:00 +0800 Message-ID: <001201cee41e$4358fbe0$ca0af3a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7kBl1dV7mVT9klTqKuTFbbCThaYg== Content-Language: zh-cn Cc: nvo3@ietf.org, 'Lucy yong' Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 05:23:10 -0000 >From my understanding of NVO3, the NVA should be a centralized entity, = and fully decoupled from NVE physically or logically. The mapping tables in = NVE should be from NVA, not from NVE. I agree with Thomas's statement below. When we are saying the control = plane between NVE and NVA, it refers only the mapping table maintenance and populating. But it does not exclude other function interaction between = NVE and NVE. I suggest to explicitly say that in the architecture draft. Regards Lizhong -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: 2013=C4=EA11=D4=C216=C8=D5 6:19 To: Yves Hertoghs (yhertogh) Cc: nvo3@ietf.org; Lucy yong Subject: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt NVO3 does not need an NVE to NVE control protocol. Calling this out explicitly, as it is consistent with the current architecture document. There is no need for an NVE to NVE control = protocol, for the purpose of maintaining/populating the mapping tables. There may = well be interactions between NVEs, such as setting up tunnels, creating = security associations for protecting data plane traffic, or providing error indications (e.g., equivalent of ICMP "TS unreachable" responses). If folk disagree, now would be a good time to have that conversation. "Yves Hertoghs (yhertogh)" writes: =20 > >> I disagree with the need for an NVE to NVE control plane. >=20 > > [Lucy] do you think we need NVE-NVE control plane? I don=E2=80=99t = think =20 > > this is what you mean from the following statement. >=20 > No we dont need an NVE to NVE control plane. >=20 > >> That doesn't mean that you can't colocate a portion of the=20 > >> distributed NVA with every NVE, which is the model that e.g.=20 > >> BGP/L3VPN or ISIS/TRILL uses. >=20 > > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >=20 > And as a result there is only a need for a control plane between the=20 > NVE function and the NVA function. Thomas From xuxiaohu@huawei.com Sun Nov 17 21:58:07 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260A511E80EC for ; Sun, 17 Nov 2013 21:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EjofYAQmEIx for ; Sun, 17 Nov 2013 21:58:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57DEA11E8164 for ; Sun, 17 Nov 2013 21:57:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXZ51655; Mon, 18 Nov 2013 05:57:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 05:57:53 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 05:57:56 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 13:57:45 +0800 From: Xuxiaohu To: Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4lDNz7UK47TOvESO3gjDk/5DK5oqgQzg Date: Mon, 18 Nov 2013 05:57:44 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08233E24@NKGEML512-MBS.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Lucy yong Subject: [nvo3] =?gb2312?b?tPC4tDogIE5vIG5lZWQgZm9yIE5WRS1OVkUgY29udHJv?= =?gb2312?b?bCBwbGFuZSBbd2FzIFJlOiBQb2xsIGZvciBXRwlhZG9wdGlvbiBhbmQgSVBS?= =?gb2312?b?IGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 05:58:07 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRob21hcw0KPiBOYXJ0ZW4NCj4g t6LLzcqxvOQ6IDIwMTPE6jEx1MIxNsjVIDY6MTkNCj4gytW8/sjLOiBZdmVzIEhlcnRvZ2hzICh5 aGVydG9naCkNCj4gs63LzTogbnZvM0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+INb3zOI6IFtudm8z XSBObyBuZWVkIGZvciBOVkUtTlZFIGNvbnRyb2wgcGxhbmUgW3dhcyBSZTogUG9sbCBmb3IgV0cg YWRvcHRpb24NCj4gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50 eHQNCj4gDQo+IE5WTzMgZG9lcyBub3QgbmVlZCBhbiBOVkUgdG8gTlZFIGNvbnRyb2wgcHJvdG9j b2wuDQo+IA0KPiBDYWxsaW5nIHRoaXMgb3V0IGV4cGxpY2l0bHksIGFzIGl0IGlzIGNvbnNpc3Rl bnQgd2l0aCB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUNCj4gZG9jdW1lbnQuIFRoZXJlIGlzIG5v IG5lZWQgZm9yIGFuIE5WRSB0byBOVkUgY29udHJvbCBwcm90b2NvbCwgZm9yIHRoZSBwdXJwb3Nl DQo+IG9mIG1haW50YWluaW5nL3BvcHVsYXRpbmcgdGhlIG1hcHBpbmcgdGFibGVzLiBUaGVyZSBt YXkgd2VsbCBiZSBpbnRlcmFjdGlvbnMNCg0KSSdkIGxpa2UgdG8ga25vdyB0aGUgcmVhc29uIGJl aGluZCB0aGF0IGRlY2lzaW9uLg0KDQpYaWFvaHUNCg0KPiBiZXR3ZWVuIE5WRXMsIHN1Y2ggYXMg c2V0dGluZyB1cCB0dW5uZWxzLCBjcmVhdGluZyBzZWN1cml0eSBhc3NvY2lhdGlvbnMgZm9yDQo+ IHByb3RlY3RpbmcgZGF0YSBwbGFuZSB0cmFmZmljLCBvciBwcm92aWRpbmcgZXJyb3IgaW5kaWNh dGlvbnMgKGUuZy4sIGVxdWl2YWxlbnQgb2YNCj4gSUNNUCAiVFMgdW5yZWFjaGFibGUiIHJlc3Bv bnNlcykuDQo+IA0KPiBJZiBmb2xrIGRpc2FncmVlLCBub3cgd291bGQgYmUgYSBnb29kIHRpbWUg dG8gaGF2ZSB0aGF0IGNvbnZlcnNhdGlvbi4NCj4gDQo+ICJZdmVzIEhlcnRvZ2hzICh5aGVydG9n aCkiIDx5aGVydG9naEBjaXNjby5jb20+IHdyaXRlczoNCj4gDQo+ID4gPj4gSSBkaXNhZ3JlZSB3 aXRoIHRoZSBuZWVkIGZvciBhbiBOVkUgdG8gTlZFIGNvbnRyb2wgcGxhbmUuDQo+ID4NCj4gPiA+ IFtMdWN5XSBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZFIGNvbnRyb2wgcGxhbmU/IEkgZG9u 4oCZdCB0aGluaw0KPiA+ID4gdGhpcyBpcyB3aGF0IHlvdSBtZWFuIGZyb20gdGhlIGZvbGxvd2lu ZyBzdGF0ZW1lbnQuDQo+ID4NCj4gPiBObyB3ZSBkb250IG5lZWQgYW4gTlZFIHRvIE5WRSBjb250 cm9sIHBsYW5lLg0KPiA+DQo+ID4gPj4gVGhhdCBkb2Vzbid0IG1lYW4gdGhhdCB5b3UgY2FuJ3Qg Y29sb2NhdGUgYSBwb3J0aW9uIG9mIHRoZQ0KPiA+ID4+IGRpc3RyaWJ1dGVkIE5WQSB3aXRoIGV2 ZXJ5IE5WRSwgd2hpY2ggaXMgdGhlIG1vZGVsIHRoYXQgZS5nLg0KPiA+ID4+IEJHUC9MM1ZQTiBv ciBJU0lTL1RSSUxMIHVzZXMuDQo+ID4NCj4gPiA+IFtMdWN5XSBBZ3JlZWQuIE5WQSBjYW4gY29s bG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBvciBlbnRpcmUpLg0KPiA+DQo+ID4gQW5kIGFzIGEg cmVzdWx0IHRoZXJlIGlzIG9ubHkgYSBuZWVkIGZvciBhIGNvbnRyb2wgcGxhbmUgYmV0d2VlbiB0 aGUNCj4gPiBOVkUgZnVuY3Rpb24gYW5kIHRoZSBOVkEgZnVuY3Rpb24uDQo+IA0KPiBUaG9tYXMN Cg0K From marc.lasserre@alcatel-lucent.com Mon Nov 18 03:58:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A1711E8204 for ; Mon, 18 Nov 2013 03:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDw6fBAgQ8tA for ; Mon, 18 Nov 2013 03:58:44 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3CE11E820B for ; Mon, 18 Nov 2013 03:58:33 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAIBwPUT009379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 05:58:26 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAIBwO90002376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 12:58:24 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 18 Nov 2013 12:58:24 +0100 From: "LASSERRE, MARC (MARC)" To: Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4lDLB3nxGHqXDEaEjvXT/Ypc9poq4Z/w Date: Mon, 18 Nov 2013 11:58:24 +0000 Message-ID: References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> In-Reply-To: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 11:58:51 -0000 VGhvbWFzLA0KDQpUaGUgd2F5IHRoYXQgeW91IGhhdmUgcGhyYXNlZCB0aGlzIHNlbnRlbmNlIGlz IGNvbmZ1c2luZyBhbmQgbmVlZHMgY2xhcmlmaWNhdGlvbi4NCg0KVmFyaW91cyBjb250cm9sIHBy b3RvY29scyBjYW4gYmUgdXNlZCBiZXR3ZWVuIE5WRXMsIGFzIHlvdSBpbmRpY2F0ZWQuDQoNCklm IHlvdSBtZWFudCB0byBzYXkgdGhhdCB0aGVyZSBpcyBubyBuZWVkIGZvciBOVkVzIHRvIGV4Y2hh bmdlIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZW1zZWx2ZXMsIHRoaXMg aXMgYWxzbyBkZWJhdGFibGUuDQpBbiBleHRlcm5hbCBOVkEgZm9yIHN1Y2ggYSBmdW5jdGlvbiBp cyBub3QgYWx3YXlzIHJlcXVpcmVkIGluIG52bzMuIFdoZW4gdGhlIE5WQSBhZGRyZXNzIG1hcHBp bmcgZnVuY3Rpb24gaXMgY29sb2NhdGVkIHdpdGggYW4gTlZFLCBOVkVzIGFwcGVhciBhcyBleGNo YW5naW5nIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbiAoanVzdCBsb29raW5nIGF0IHRoZSB3 aXJlKS4gSUdQcyB3aXRoaW4gTlZFcyBhbHNvIGV4Y2hhbmdlIHRvcG9sb2dpY2FsL2FkZHJlc3Mg bWFwcGluZyBpbmZvcm1hdGlvbi4NCg0KTWFyYw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gDQo+IEJlaGFsZiBPZiBUaG9tYXMgTmFydGVuDQo+IFNlbnQ6IEZyaWRheSwg Tm92ZW1iZXIgMTUsIDIwMTMgMTE6MTkgUE0NCj4gVG86IFl2ZXMgSGVydG9naHMgKHloZXJ0b2do KQ0KPiBDYzogbnZvM0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+IFN1YmplY3Q6IFtudm8zXSBObyBu ZWVkIGZvciBOVkUtTlZFIGNvbnRyb2wgcGxhbmUgW3dhcyBSZTogDQo+IFBvbGwgZm9yIFdHIGFk b3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+ IA0KPiBOVk8zIGRvZXMgbm90IG5lZWQgYW4gTlZFIHRvIE5WRSBjb250cm9sIHByb3RvY29sLg0K PiANCj4gQ2FsbGluZyB0aGlzIG91dCBleHBsaWNpdGx5LCBhcyBpdCBpcyBjb25zaXN0ZW50IHdp dGggdGhlIA0KPiBjdXJyZW50IGFyY2hpdGVjdHVyZSBkb2N1bWVudC4gVGhlcmUgaXMgbm8gbmVl ZCBmb3IgYW4gTlZFIHRvIA0KPiBOVkUgY29udHJvbCBwcm90b2NvbCwgZm9yIHRoZSBwdXJwb3Nl IG9mIA0KPiBtYWludGFpbmluZy9wb3B1bGF0aW5nIHRoZSBtYXBwaW5nIHRhYmxlcy4gVGhlcmUg bWF5IHdlbGwgYmUgDQo+IGludGVyYWN0aW9ucyBiZXR3ZWVuIE5WRXMsIHN1Y2ggYXMgc2V0dGlu ZyB1cCB0dW5uZWxzLCANCj4gY3JlYXRpbmcgc2VjdXJpdHkgYXNzb2NpYXRpb25zIGZvciBwcm90 ZWN0aW5nIGRhdGEgcGxhbmUgDQo+IHRyYWZmaWMsIG9yIHByb3ZpZGluZyBlcnJvciBpbmRpY2F0 aW9ucyAoZS5nLiwgZXF1aXZhbGVudCBvZiANCj4gSUNNUCAiVFMgdW5yZWFjaGFibGUiIHJlc3Bv bnNlcykuDQo+IA0KPiBJZiBmb2xrIGRpc2FncmVlLCBub3cgd291bGQgYmUgYSBnb29kIHRpbWUg dG8gaGF2ZSB0aGF0IGNvbnZlcnNhdGlvbi4NCj4gDQo+ICJZdmVzIEhlcnRvZ2hzICh5aGVydG9n aCkiIDx5aGVydG9naEBjaXNjby5jb20+IHdyaXRlczoNCj4gIA0KPiA+ID4+IEkgZGlzYWdyZWUg d2l0aCB0aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPiA+IA0KPiA+ ID4gW0x1Y3ldIGRvIHlvdSB0aGluayB3ZSBuZWVkIE5WRS1OVkUgY29udHJvbCBwbGFuZT8gSSAN Cj4gZG9uw6LigqzihKJ0IHRoaW5rICANCj4gPiA+IHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBmcm9t IHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50Lg0KPiA+IA0KPiA+IE5vIHdlIGRvbnQgbmVlZCBhbiBO VkUgdG8gTlZFIGNvbnRyb2wgcGxhbmUuDQo+ID4gDQo+ID4gPj4gVGhhdCBkb2Vzbid0IG1lYW4g dGhhdCB5b3UgY2FuJ3QgY29sb2NhdGUgYSBwb3J0aW9uIG9mIHRoZSANCj4gPiA+PiBkaXN0cmli dXRlZCBOVkEgd2l0aCBldmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUuZy4gDQo+ ID4gPj4gQkdQL0wzVlBOIG9yIElTSVMvVFJJTEwgdXNlcy4NCj4gPiANCj4gPiA+IFtMdWN5XSBB Z3JlZWQuIE5WQSBjYW4gY29sbG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBvciBlbnRpcmUpLg0K PiA+IA0KPiA+IEFuZCBhcyBhIHJlc3VsdCB0aGVyZSBpcyBvbmx5IGEgbmVlZCBmb3IgYSBjb250 cm9sIHBsYW5lIA0KPiBiZXR3ZWVuIHRoZSANCj4gPiBOVkUgZnVuY3Rpb24gYW5kIHRoZSBOVkEg ZnVuY3Rpb24uDQo+IA0KPiBUaG9tYXMNCj4gDQo+IA== From linda.dunbar@huawei.com Mon Nov 18 07:41:16 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389F811E813B for ; Mon, 18 Nov 2013 07:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7an3MglhO1s6 for ; Mon, 18 Nov 2013 07:41:09 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A54E511E8172 for ; Mon, 18 Nov 2013 07:37:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYA07627; Mon, 18 Nov 2013 15:37:53 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 15:37:38 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 15:37:42 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 07:37:31 -0800 From: Linda Dunbar To: Dino Farinacci Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4mH2UY5GfcqPX0a6/7q+q7gqa5orInhw Date: Mon, 18 Nov 2013 15:37:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> In-Reply-To: <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nvo3@ietf.org" , Lucy yong , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 15:41:16 -0000 Dino,=20 >If the destination NVEs don't > exist, those packets go to black hole. >=20 > Yes, it is. But a NVE could be unreachable and if the encapsulating NVE > has a choice to select another NVE to encapsulate to, it should. This > makes the architecture more robust. You don't need control plane protocol to achieve what you are asking here. = A simple TCP session among NVEs can do the job. When a NVE can't reach the = egress NVE to which the target is attached, drop the packet.=20 Linda From farinacci@gmail.com Mon Nov 18 09:10:23 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF18811E8160 for ; Mon, 18 Nov 2013 09:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUXhIQAzbGVu for ; Mon, 18 Nov 2013 09:10:23 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB5011E818F for ; Mon, 18 Nov 2013 09:09:43 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id x10so6785131pdj.18 for ; Mon, 18 Nov 2013 09:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V/e5F3DODt1FN4GFfMb8eo3lUOh5XG/5Eo1OJnQT1lY=; b=eDNvH42Pd6kaQKP4+SKxtPyL1fWdPzCEue8MNj0A5VcjCYk5eloBW+TcjoMdVqn/DV ROxfSGv2LvQc89DqXTq+WWPk+dt9Uo1hCG+E3vpCHFuOrf7xoxflpUKqWEpillBW6Lhw H3JnSQz92vA1MuHk60l6Lekr/YVgp7UU46ZclIlonlzXr8pjGFHC72LmrLA+JLNTN/mH +9Ff351/nX9ch33ctXexLvh037T0/aSuVEDlPbe/Uzl9TLA/pw2vrgUT81+UpyXNCSkN +xylL1sbXWk+7DDZvROnXzmcyZOizfqiM6lM7U9hXIo5JxeRohM59VSB19xgMfHBsNvw L+6A== X-Received: by 10.66.129.169 with SMTP id nx9mr3772582pab.130.1384794583050; Mon, 18 Nov 2013 09:09:43 -0800 (PST) Received: from [192.168.1.101] ([207.145.253.66]) by mx.google.com with ESMTPSA id oj6sm27977729pab.9.2013.11.18.09.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 09:09:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> Date: Mon, 18 Nov 2013 09:09:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <376EC087-9596-4534-988E-1E611A596B54@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" , Lucy Yong , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:10:23 -0000 Dino,=20 >=20 >> If the destination NVEs don't >> exist, those packets go to black hole. >>=20 >> Yes, it is. But a NVE could be unreachable and if the encapsulating = NVE >> has a choice to select another NVE to encapsulate to, it should. This >> makes the architecture more robust. >=20 > You don't need control plane protocol to achieve what you are asking = here. A simple TCP session among NVEs can do the job. When a NVE can't = reach the egress NVE to which the target is attached, drop the packet.=20= That is a form of a control-plane protocol. And you will have to same = scaling challenges with TCP and arguably it is worse, since TCP, = inherently, does not have keepalives. Dino >=20 >=20 > Linda >=20 From linda.dunbar@huawei.com Mon Nov 18 09:50:59 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847011E81C6 for ; Mon, 18 Nov 2013 09:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O31fqbtO0J-H for ; Mon, 18 Nov 2013 09:50:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 39E9311E825E for ; Mon, 18 Nov 2013 09:43:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYA16158; Mon, 18 Nov 2013 17:43:34 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 17:43:29 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 17:43:34 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 09:43:24 -0800 From: Linda Dunbar To: Dino Farinacci Thread-Topic: NVO3 needs a boundary for the problem domain ( was RE: [nvo3] No need for NVE-NVE control plane) Thread-Index: AQHO5IWuZ3YheWWodU+z15XckMvKMA== Date: Mon, 18 Nov 2013 17:43:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C1B8AB@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> <376EC087-9596-4534-988E-1E611A596B54@gmail.com> In-Reply-To: <376EC087-9596-4534-988E-1E611A596B54@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nvo3@ietf.org" , Lucy yong , "Yves Hertoghs $yhertogh$" Subject: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:50:59 -0000 Dino,=20 So you are asking for a simple keep alive among NVEs (i.e. simpler than TCP= ) for NVEs to be aware if the target egress NVEs are not reachable.=20 That might be good to have, depending on the environment.=20 With this so called "control protocol", the packets will be dropped at the = Ingress NVE when egress NVE is not reachable. =20 Without this so called "control protocol, the packets will be dropped somew= here in the network when the egress NVE is not reachable. =20 In data center environment where most communications are among applications= , most likely a source will not send more packets without acknowledgment fr= om the destination. Then the impact of where the packet is dropped is not t= hat big.=20 But in an environment where NVEs have aggregated traffic from many sources/= flows, then it is important to have this "control protocol". In this enviro= nment, it might even warrant a control plane for NVE to notify the source w= hen the egress is not reachable, so the source can choose a different ingre= ss NVE.=20 Bottom-line: I truly think that NVO3 needs a better boundary on the problem= domain. If NVO3 is targeted for solving problems for entire worldwide inte= rnet, you need many control plane protocols. If NVO3 is targeted for solvin= g problems in data centers, then many control plane protocols becomes unnec= essary.=20 Linda > -----Original Message----- > > > > You don't need control plane protocol to achieve what you are asking > here. A simple TCP session among NVEs can do the job. When a NVE can't > reach the egress NVE to which the target is attached, drop the packet. >=20 > That is a form of a control-plane protocol. And you will have to same > scaling challenges with TCP and arguably it is worse, since TCP, > inherently, does not have keepalives. >=20 > Dino >=20 > > > > > > Linda > > From farinacci@gmail.com Mon Nov 18 09:52:16 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5664411E8152 for ; Mon, 18 Nov 2013 09:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFHodWG2I+Bm for ; Mon, 18 Nov 2013 09:52:15 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id AA07D11E8271 for ; Mon, 18 Nov 2013 09:47:21 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so614717pbb.37 for ; Mon, 18 Nov 2013 09:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fdit+87ZM29pptd+ATiQtuZYMfpPIMfy1RdKt4yDx3E=; b=rx0FgL0QdMlrMeMMAO3fh2rwvRt2/h5pDEdFjqgkYvGWEReU37wYTm/ZEa04oD7SDb tJpRq0gt48voIxGJupP5XJ19SUpUbmj+8+B2NYwlm3690NeJZDhSY4AdaGBd60OmxKfM IsHCSAPPHbqYxivbUfdIrqAscx2RgswuisDG6ibdCki5zpI+PonHoE0Z8FbXrwddS6uO rAXWhQnj/kcgdG0OUFP2yJg2Bdr0UWEQNqVSpG85NgdrlmIpLZsaD/JXMS3XkCeraCId tYaQzjEIeRzAPeZktnaC3qa1a+TjOIwy0is3w47ic4/IIOPdPonVHcnFWNqckvifZ6OK btdg== X-Received: by 10.68.170.225 with SMTP id ap1mr14626541pbc.117.1384796835391; Mon, 18 Nov 2013 09:47:15 -0800 (PST) Received: from [192.168.1.101] ([207.145.253.66]) by mx.google.com with ESMTPSA id m2sm24822471pbn.19.2013.11.18.09.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 09:47:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C1B8AB@dfweml509-mbx.china.huawei.com> Date: Mon, 18 Nov 2013 09:47:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <878A294A-8CEB-4AAF-AAA1-F7C63869D0F2@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> <376EC087-9596-4534-988E-1E611A596B54@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B8AB@dfweml509-mbx.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" , Lucy Yong , "Yves Hertoghs $yhertogh$" Subject: Re: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 17:52:16 -0000 > With this so called "control protocol", the packets will be dropped at = the Ingress NVE when egress NVE is not reachable. =20 Only if *all* the NVEs for the EID? (what do you guys call the things = behind the NVE) are unreachable. > Without this so called "control protocol, the packets will be dropped = somewhere in the network when the egress NVE is not reachable. =20 Right. > In data center environment where most communications are among = applications, most likely a source will not send more packets without = acknowledgment from the destination. Then the impact of where the packet = is dropped is not that big.=20 You have to make this work for UDP applications. > But in an environment where NVEs have aggregated traffic from many = sources/flows, then it is important to have this "control protocol". In = this environment, it might even warrant a control plane for NVE to = notify the source when the egress is not reachable, so the source can = choose a different ingress NVE.=20 No comment. ;-) But that works naturally in MPTCP by the way. > Bottom-line: I truly think that NVO3 needs a better boundary on the = problem domain. If NVO3 is targeted for solving problems for entire = worldwide internet, you need many control plane protocols. If NVO3 is = targeted for solving problems in data centers, then many control plane = protocols becomes unnecessary.=20 Dino From sbarkai@gmail.com Mon Nov 18 10:41:16 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4B71A1F50 for ; Mon, 18 Nov 2013 10:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqcmaT4LiT75 for ; Mon, 18 Nov 2013 10:41:15 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE9B1A1F4F for ; Mon, 18 Nov 2013 10:41:12 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id up15so2379801pbc.24 for ; Mon, 18 Nov 2013 10:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=arsk0bMoUVjcHIXMlzPh7ItGGjY+uPhJAI6Hrsv2frg=; b=eEX/3fVczjFajGa3sGKwSrMVJZxOToMB/P8xL8FiPcTPVsfkl6t9+3VjD5YCOUYpgk +rLLWOms+F2UMirbgSJx+w/QLYLWGHY2UpvC5ZLcjRcnmmXtKz5aCJlSuMIprZaJURkr +erEg4dwcMxAXtODUu/D7lUOsLsLHA0fU0uCfuRw9DnkGB7CDO7VfGuYiB3MOtrEgo6U gVnAidQ2uzj2rbi8AjngYL+FmvOiSEyc6a7T+fAL5woxoemLZcuX4ITCJsjFoUE7eC41 BMNs/2iMEybw6jDTvTbshqdy5eWpvQqEDGevdebgFCvBrT/+Dybl6FLHpnDyui3a2j14 Gf/Q== X-Received: by 10.68.103.163 with SMTP id fx3mr14803506pbb.59.1384798546876; Mon, 18 Nov 2013 10:15:46 -0800 (PST) Received: from [10.10.120.180] (50-197-184-177-static.hfc.comcastbusiness.net. [50.197.184.177]) by mx.google.com with ESMTPSA id p1sm24949858pbo.12.2013.11.18.10.15.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 10:15:45 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sharon X-Mailer: iPhone Mail (11B554a) In-Reply-To: <878A294A-8CEB-4AAF-AAA1-F7C63869D0F2@gmail.com> Date: Mon, 18 Nov 2013 10:15:44 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1CAEFE8E-4CBF-4808-B283-E34495EFE328@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com> <376EC087-9596-4534-988E-1E611A596B54@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B8AB@dfweml509-mbx.china.huawei.com> <878A294A-8CEB-4AAF-AAA1-F7C63869D0F2@gmail.com> To: Dino Farinacci Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy Yong , Linda Dunbar Subject: Re: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 18:41:16 -0000 > On Nov 18, 2013, at 9:47 AM, Dino Farinacci wrote: >=20 > Only if *all* the NVEs for the EID? (what do you guys call the things behi= nd the NVE) are unreachable. These things behind the NVE (in the outer-lay segments) need a name. Not jus= t their general EID, but their connection to a given NVE aggregation right n= ow. From jnc@mercury.lcs.mit.edu Mon Nov 18 11:22:00 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969D81AE004 for ; Mon, 18 Nov 2013 11:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbqIPrdj8jgQ for ; Mon, 18 Nov 2013 11:21:59 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8128D1ADF4D for ; Mon, 18 Nov 2013 11:21:59 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 80B8018C168; Mon, 18 Nov 2013 14:21:53 -0500 (EST) To: nvo3@ietf.org Message-Id: <20131118192153.80B8018C168@mercury.lcs.mit.edu> Date: Mon, 18 Nov 2013 14:21:53 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:22:00 -0000 > From: Sharon > These things behind the NVE (in the outer-lay segments) need a name. > Not just their general EID, but their connection to a given NVE > aggregation right now. You mean their RLOC? {Ducks} Noel From kreeger@cisco.com Mon Nov 18 11:22:40 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532B81AE083 for ; Mon, 18 Nov 2013 11:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.126 X-Spam-Level: X-Spam-Status: No, score=-13.126 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH86eVa240sg for ; Mon, 18 Nov 2013 11:22:38 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B5DFF1AE080 for ; Mon, 18 Nov 2013 11:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2200; q=dns/txt; s=iport; t=1384802553; x=1386012153; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VoGd24TYMi0E9dskYXzA0VxQ+Rkdr7wYTsxm6a+5XN4=; b=Wv4C16Cx/+g5wHxvbcj7Y3/I9iIqK4TdqLyvgyqEMSZD79HcaQbbDbKY QZDRKiDvtabQ6g/Cy8VOAod2/9RnIvC5/9akhm2z9rC5RiygWFwmpCS34 s+kGzROnLXjZfF9cs2Rm4v3mYXRl0QjEYST0V3YvqQuQq113OJEwPlevW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFALpYilKtJXG9/2dsb2JhbABZgwc4U781gR4WdIIlAQEBBAEBATc0CwwGAQg2BTILJQIEAQ0FG4dmDcJKEwSPaQeEMQOTbIQkkg2BaoE+gio X-IronPort-AV: E=Sophos;i="4.93,725,1378857600"; d="scan'208";a="285692654" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 18 Nov 2013 18:15:12 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAIIFC6o009767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 18:15:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 12:15:12 -0600 From: "Larry Kreeger (kreeger)" To: Linda Dunbar , Dino Farinacci Thread-Topic: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) Thread-Index: AQHO5IbZueqTNgBIaUao+445KxFmIporGOKA Date: Mon, 18 Nov 2013 18:15:10 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C1B8AB@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.21.90.50] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy yong Subject: Re: [nvo3] NVO3 needs a boundary for the problem domain ( was RE: No need for NVE-NVE control plane) X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:22:40 -0000 On 11/18/13 9:43 AM, "Linda Dunbar" wrote: >Dino,=20 > >So you are asking for a simple keep alive among NVEs (i.e. simpler than >TCP) for NVEs to be aware if the target egress NVEs are not reachable. > >That might be good to have, depending on the environment. > >With this so called "control protocol", the packets will be dropped at >the Ingress NVE when egress NVE is not reachable. >Without this so called "control protocol, the packets will be dropped >somewhere in the network when the egress NVE is not reachable. > >In data center environment where most communications are among >applications, most likely a source will not send more packets without >acknowledgment from the destination. Then the impact of where the packet >is dropped is not that big. > >But in an environment where NVEs have aggregated traffic from many >sources/flows, then it is important to have this "control protocol". In >this environment, it might even warrant a control plane for NVE to notify >the source when the egress is not reachable, so the source can choose a >different ingress NVE. > >Bottom-line: I truly think that NVO3 needs a better boundary on the >problem domain. If NVO3 is targeted for solving problems for entire >worldwide internet, you need many control plane protocols. If NVO3 is >targeted for solving problems in data centers, then many control plane >protocols becomes unnecessary. LK> I think the charter is clear that NVO3 is targeted for data center solutions. >=20 > >Linda > > >> -----Original Message----- >> > >> > You don't need control plane protocol to achieve what you are asking >> here. A simple TCP session among NVEs can do the job. When a NVE can't >> reach the egress NVE to which the target is attached, drop the packet. >>=20 >> That is a form of a control-plane protocol. And you will have to same >> scaling challenges with TCP and arguably it is worse, since TCP, >> inherently, does not have keepalives. >>=20 >> Dino >>=20 >> > >> > >> > Linda >> > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From kgray@juniper.net Mon Nov 18 11:25:15 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEEC1AE08B for ; Mon, 18 Nov 2013 11:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyxIPAyqlu6l for ; Mon, 18 Nov 2013 11:25:13 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 32E241AE09B for ; Mon, 18 Nov 2013 11:25:13 -0800 (PST) Received: from mail65-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Nov 2013 19:25:07 +0000 Received: from mail65-am1 (localhost [127.0.0.1]) by mail65-am1-R.bigfish.com (Postfix) with ESMTP id 0C4BC1C032D; Mon, 18 Nov 2013 19:25:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z579eh579fhzdb82h9371Ic89bh542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h946hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail65-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(51704005)(13464003)(46102001)(54356001)(74706001)(79102001)(53806001)(74876001)(51856001)(47446002)(74502001)(59766001)(77982001)(81342001)(56776001)(63696002)(54316002)(85306002)(83072001)(66066001)(76482001)(80022001)(76576001)(49866001)(65816001)(31966008)(76786001)(81686001)(47976001)(74662001)(47736001)(76796001)(80976001)(87936001)(81542001)(50986001)(69226001)(15975445006)(77096001)(2656002)(56816003)(87266001)(561944002)(33646001)(81816001)(224313003)(74366001)(224303002)(83322001)(74316001)(19580395003)(4396001)(19580405001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB084; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.15; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail65-am1 (localhost.localdomain [127.0.0.1]) by mail65-am1 (MessageSwitch) id 1384802703901036_8639; Mon, 18 Nov 2013 19:25:03 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.240]) by mail65-am1.bigfish.com (Postfix) with ESMTP id CDEE56043C; Mon, 18 Nov 2013 19:25:03 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 18 Nov 2013 19:25:03 +0000 Received: from BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 18 Nov 2013 19:24:56 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 19:24:55 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.246]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 19:24:55 +0000 From: Ken Gray To: "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5FWdPpmOculA5EutupDOtAaweJorXeDt Date: Mon, 18 Nov 2013 19:24:54 +0000 Message-ID: <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.15] x-forefront-prvs: 00342DD5BC Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:25:15 -0000 I don't think the logical association of the NVA with an NVE negates Thomas= basic point. The key word you use here is "appears" ... in the end, it's = not the NVE that other NVEs are exchanging mapping information with, it is = the NVA that is co-located.=0A= =0A= +1 for Thomas proposal. YES, you can make it more explicit in the architec= ture that "mapping" is what you are talking about instead of the generic "c= ontrol".=0A= =0A= We can beat NVE-NVE liveliness to death with other truncheons.=0A= ________________________________________=0A= From: nvo3-bounces@ietf.org on behalf of LASSERRE, = MARC (MARC) =0A= Sent: Monday, November 18, 2013 6:58 AM=0A= To: Thomas Narten; Yves Hertoghs (yhertogh)=0A= Cc: nvo3@ietf.org; Lucy yong=0A= Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt=0A= =0A= Thomas,=0A= =0A= The way that you have phrased this sentence is confusing and needs clarific= ation.=0A= =0A= Various control protocols can be used between NVEs, as you indicated.=0A= =0A= If you meant to say that there is no need for NVEs to exchange address mapp= ing information between themselves, this is also debatable.=0A= An external NVA for such a function is not always required in nvo3. When th= e NVA address mapping function is colocated with an NVE, NVEs appear as exc= hanging address mapping information (just looking at the wire). IGPs within= NVEs also exchange topological/address mapping information.=0A= =0A= Marc=0A= =0A= > -----Original Message-----=0A= > From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On=0A= > Behalf Of Thomas Narten=0A= > Sent: Friday, November 15, 2013 11:19 PM=0A= > To: Yves Hertoghs (yhertogh)=0A= > Cc: nvo3@ietf.org; Lucy yong=0A= > Subject: [nvo3] No need for NVE-NVE control plane [was Re:=0A= > Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt=0A= >=0A= > NVO3 does not need an NVE to NVE control protocol.=0A= >=0A= > Calling this out explicitly, as it is consistent with the=0A= > current architecture document. There is no need for an NVE to=0A= > NVE control protocol, for the purpose of=0A= > maintaining/populating the mapping tables. There may well be=0A= > interactions between NVEs, such as setting up tunnels,=0A= > creating security associations for protecting data plane=0A= > traffic, or providing error indications (e.g., equivalent of=0A= > ICMP "TS unreachable" responses).=0A= >=0A= > If folk disagree, now would be a good time to have that conversation.=0A= >=0A= > "Yves Hertoghs (yhertogh)" writes:=0A= >=0A= > > >> I disagree with the need for an NVE to NVE control plane.=0A= > >=0A= > > > [Lucy] do you think we need NVE-NVE control plane? I=0A= > don=E2=80=99t think=0A= > > > this is what you mean from the following statement.=0A= > >=0A= > > No we dont need an NVE to NVE control plane.=0A= > >=0A= > > >> That doesn't mean that you can't colocate a portion of the=0A= > > >> distributed NVA with every NVE, which is the model that e.g.=0A= > > >> BGP/L3VPN or ISIS/TRILL uses.=0A= > >=0A= > > > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire).=0A= > >=0A= > > And as a result there is only a need for a control plane=0A= > between the=0A= > > NVE function and the NVA function.=0A= >=0A= > Thomas=0A= >=0A= >=0A= _______________________________________________=0A= nvo3 mailing list=0A= nvo3@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nvo3=0A= From kgray@juniper.net Mon Nov 18 11:54:34 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F271AE24D for ; Mon, 18 Nov 2013 11:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdvzWOYhxQVN for ; Mon, 18 Nov 2013 11:54:32 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id CB3AF1AE245 for ; Mon, 18 Nov 2013 11:54:32 -0800 (PST) Received: from mail125-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Mon, 18 Nov 2013 19:54:26 +0000 Received: from mail125-tx2 (localhost [127.0.0.1]) by mail125-tx2-R.bigfish.com (Postfix) with ESMTP id D6BBF300768; Mon, 18 Nov 2013 19:54:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(z579ehz9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail125-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(377454003)(51704005)(46102001)(54356001)(74706001)(79102001)(53806001)(74876001)(51856001)(47446002)(74502001)(59766001)(77982001)(81342001)(56776001)(63696002)(54316002)(85306002)(66066001)(80022001)(76482001)(76576001)(49866001)(65816001)(31966008)(83072001)(76786001)(81686001)(47976001)(74662001)(47736001)(76796001)(80976001)(87936001)(81542001)(50986001)(69226001)(15975445006)(77096001)(2656002)(56816003)(87266001)(33646001)(81816001)(224313003)(74366001)(224303002)(74316001)(83322001)(19580395003)(4396001)(19580405001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB084; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail125-tx2 (localhost.localdomain [127.0.0.1]) by mail125-tx2 (MessageSwitch) id 1384804465650424_934; Mon, 18 Nov 2013 19:54:25 +0000 (UTC) Received: from TX2EHSMHS014.bigfish.com (unknown [10.9.14.233]) by mail125-tx2.bigfish.com (Postfix) with ESMTP id 9960C180069; Mon, 18 Nov 2013 19:54:25 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS014.bigfish.com (10.9.99.114) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 18 Nov 2013 19:54:25 +0000 Received: from BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 18 Nov 2013 19:54:24 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 18 Nov 2013 19:54:23 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.246]) with mapi id 15.00.0820.005; Mon, 18 Nov 2013 19:54:23 +0000 From: Ken Gray To: Dino Farinacci , Linda Dunbar Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5IEfQzpQt+A72EivnIqeeLhYxJorZled Date: Mon, 18 Nov 2013 19:54:22 +0000 Message-ID: <1ba9bd6e64674f978c49b4c9abcddd77@BL2PR05MB082.namprd05.prod.outlook.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com>, <376EC087-9596-4534-988E-1E611A596B54@gmail.com> In-Reply-To: <376EC087-9596-4534-988E-1E611A596B54@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 00342DD5BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy Yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:54:34 -0000 Unless it's built at a lower layer than a piggy-back app, it's going to be = a scale monster (IMO, if you plan for success, then ultimately you have hig= hly connected NVEs - hello scale monster). Something like CFM for overlays= (logical ethernet, logical continuity check built into your header as a sp= ecial packet type, punt to momma NVE process ...not some cousin, etc?)? = =3D8^)=0A= ________________________________________=0A= From: nvo3-bounces@ietf.org on behalf of Dino Farin= acci =0A= Sent: Monday, November 18, 2013 12:09 PM=0A= To: Linda Dunbar=0A= Cc: Thomas Narten; nvo3@ietf.org; Lucy Yong; Yves Hertoghs (yhertogh)=0A= Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG = adoption and IPR check for draft-narten-nvo3-arch-01.txt=0A= =0A= Dino,=0A= >=0A= >> If the destination NVEs don't=0A= >> exist, those packets go to black hole.=0A= >>=0A= >> Yes, it is. But a NVE could be unreachable and if the encapsulating NVE= =0A= >> has a choice to select another NVE to encapsulate to, it should. This=0A= >> makes the architecture more robust.=0A= >=0A= > You don't need control plane protocol to achieve what you are asking here= . A simple TCP session among NVEs can do the job. When a NVE can't reach th= e egress NVE to which the target is attached, drop the packet.=0A= =0A= That is a form of a control-plane protocol. And you will have to same scali= ng challenges with TCP and arguably it is worse, since TCP, inherently, doe= s not have keepalives.=0A= =0A= Dino=0A= =0A= >=0A= >=0A= > Linda=0A= >=0A= =0A= _______________________________________________=0A= nvo3 mailing list=0A= nvo3@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nvo3=0A= =0A= =0A= From linda.dunbar@huawei.com Mon Nov 18 12:11:02 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D03F1ADFB1 for ; Mon, 18 Nov 2013 12:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.725 X-Spam-Level: X-Spam-Status: No, score=-3.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_BACKHAIR_33=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 088XkVSiKI9D for ; Mon, 18 Nov 2013 12:10:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 011C31AE28D for ; Mon, 18 Nov 2013 12:10:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYB01076; Mon, 18 Nov 2013 20:10:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 20:10:33 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 18 Nov 2013 20:10:38 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 12:10:31 -0800 From: Linda Dunbar To: "Black, David" , Jon Hudson , Larry Kreeger , "LASSERRE, MARC (MARC)" , Thomas Narten Thread-Topic: Sugggested addition-replacement to draft-narten-nvo3-arch-01 Thread-Index: Ac7kmjpvxpeY2oWbS1m72ky9rf0GWw== Date: Mon, 18 Nov 2013 20:10:30 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C1BA4F@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645C1BA4Fdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "adrian@olddog.co.uk" , "nvo3@ietf.org" Subject: [nvo3] Sugggested addition-replacement to draft-narten-nvo3-arch-01 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:11:02 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645C1BA4Fdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I posted those comments and suggested text changes during the WG Adoption p= rocess. Since I haven't heard any replies from the authors, I am re-posting= my suggested addition and change of text to draft-narten-nvo3-arch-01 plus= a few more suggestions to clear out issues being discussed on the mailing = list. Issues with the current writing of Distributed Gateway (Section 5.4): As described in Section 5.3, a Gateway does many things. However, I don't t= hink that a NVE, if taking on the responsibility of a distributed Gateway, = will do all the things that a conventional Gateway does (or the list of ite= ms mentioned in the Section 5.3). First, it might be too much to ask a NVE based gateway (especially Hypervis= or based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * serve as IPSec gateway to external (i.e. out of Virtual Networks)= , * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE (it is debatable if a NVE based distributed Gateway should take this r= esponsibility) The meaningful functions performed by NVE, if designated as "distributed ga= teway", are more like Inter-VN relay (instead of full blown Gateway functio= n). Second, when host "a" in VN-1 sends traffic to "b" in VN-2, the data packet= 's Ethernet header has "MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D = VN-1". Most implementations (Microsoft Window 8 and VM NSX) allocate a "fa= ke MAC" for all the NVE based distributed gateways to share, so that host "= a" can use the same Gateway-MAC when moved to another NVE. This again is di= fferent from the conventional gateways. Third, the issue of conventional gateway (i.e. a->b traffic to be routed at= gateway even if "a" & "b" are attached to the same NVE) is traffic "hairpi= nning", instead of triangular routing. Therefore, I suggest rewriting Section 5.4 as below: 5.4 Distributed Gateway (Re-write) The relaying of traffic from one VN to another, especially when Source and = Destination are attached to the same NVE, deserves special consideration. W= ith conventional Gateways, the traffic between TSes on different VNs has to= be traversed to the gateway, even if the Source and Destination are attach= ed to the save NVE, which causes traffic hairpinning and wasted bandwidth. As an optimization, it is desirable for individual NVEs to take over the in= ter-VN relay responsibilities that are traditionally done by conventional g= ateways to reduce or eliminate hairpinning issue. In order for NVEs to perf= orm inter-VN relay, the NVEs must have access to the policy information nee= ded to determine whether inter-VN communication is allowed. Those inter-VN = communication policies are most likely to come from NVA. However, it is not practical for NVEs to take over all functions of convent= ional gateways. In particular, it might be too much to ask a NVE based gateway (especially = Hypervisor based NVE) to * relay traffic off the virtual networks, i.e. perform gateway funct= ion to reach destinations outside the local VNs, * serve as IPSec gateway to external traffic * perform NAT on the source virtual addresses, or * relay traffic to a VN that doesn't have any hosts attached to the = NVE. The NVEs that are capable of performing inter-VN replaying are called "Dist= ributed Gateway" in this document. (Note: Inter-VN relaying capable NVE is = a more accurate term). The NVO3 architecture should support distributed gateways, at least allowin= g some NVEs, if not all, supporting the inter-VN relaying function, especia= lly when both source and destination are attached to the same NVE. Such su= pport requires the NVO3 control protocols include mechanisms for the mainte= nance and distribution of the inter-VN policy information to the NVEs that = are capable of performing inter-VN communications. There are many emails on the list with regard to the necessity of having NV= E<->NVE control plane protocol. All those emails discussion warrants a subs= ection under Section 4 to explain why/how the consequence of not having NVE= <->NVE control plane protocol is a minor issue (or not worth addressing) in= the environment addressed by NVO3. Here is my suggested text: 4.4 Is it necessary to have Inter-NVE control plane protocol? (Suggested ne= w sub-section) There could be various reasons, link failure, node failure, or others, caus= ing egress NVEs not reachable. Without any NVE<->NVE control plane protocol= , the ingress NVE is not aware of the reachability of egress NVE causing en= capsulated packets to dropped somewhere in the underlay network. If most TSes are only attached to a single NVE and traffic to NVEs are not= aggregated flows, then the NVE-NVE control plane protocol doesn't provide = any benefits. Under this environment, the difference between having "NVE-= NVE control protocol" is whether the packets being dropped at the Ingress N= VE or somewhere in the underlay network when egress NVE is not reachable. In data center environment where most communications are among applications= , most likely a source will not send more packets without acknowledgment fr= om the destination. Then the impact of where the packet is dropped is not t= hat big. However, in an environment where TSes are connected to multiple NVEs, then = it might be worthwhile to consider the Inter-NVE control plane protocol, so= that ingress NVE can choose different egress NVE for a given target. Thanks for considering my suggested text. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645C1BA4Fdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

I posted those com= ments and suggested text changes during the WG Adoption process. Since I ha= ven’t heard any replies from the authors, I am re-posting my suggeste= d addition and change of text to draft-narten-nvo3-arch-01 plus a few more suggestions to clear out issues being discussed on the mai= ling list.

<= /p>

Issues with the current writing of Distributed Gatew= ay (Section 5.4):

As described in Section 5.3, a Gateway does many thi= ngs. However, I don’t think that a NVE, if taking on the responsibili= ty of a distributed Gateway, will do all the things that a conventional Gat= eway does (or the list of items mentioned in the Section 5.3).

First, it might be too much to ask a NVE based gatew= ay (especially Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e.= perform gateway function to reach destinations outside the local VNs, = ;

·        serve as IPSec gateway to external (i.= e. out of Virtual Networks),

·        perform NAT on the source virtual addresses,= or

·        relay traffic to a VN that doesn’t hav= e any hosts attached to the NVE (it is debatable if a NVE based distr= ibuted Gateway should take this responsibility)

The meaningful functions= performed by NVE, if designated as “distributed gateway”, are = more like Inter-VN relay (instead of full blown Gateway function).=

Second, when host “a” in VN-1 sends traf= fic to “b” in VN-2, the data packet’s Ethernet header has= “MAC-DA =3D Gateway-MAC & MAC-SA=3D a-MAC & VLAN=3D VN-1R= 21;. Most implementations (Microsoft Window 8 and VM NSX) allocate a = “fake MAC” for all the NVE based distributed gateways to share, so that host “a” can = use the same Gateway-MAC when moved to another NVE. This again is different= from the conventional gateways.

Third, the issue of conventional gateway (i.e. a->= ;b traffic to be routed at gateway even if “a” & “b&#= 8221; are attached to the same NVE) is traffic “hairpinning”, i= nstead of triangular routing.

Therefore, I suggest rewriting Section 5.4 as below:=

5.4 Distributed Gateway (Re-write)=

The relaying of traffic from one VN to another, espe= cially when Source and Destination are attached to the same NVE, deserves s= pecial consideration. With conventional Gateways, the traffic between TSes = on different VNs has to be traversed to the gateway, even if the Source and Destination are attached to the sav= e NVE, which causes traffic hairpinning and wasted bandwidth.

As an optimization, it is desirable for individual N= VEs to take over the inter-VN relay responsibilities that are traditionally= done by conventional gateways to reduce or eliminate hairpinning issue. In= order for NVEs to perform inter-VN relay, the NVEs must have access to the policy information needed to deter= mine whether inter-VN communication is allowed. Those inter-VN communicatio= n policies are most likely to come from NVA.

However, it is not practical for NVEs to take over a= ll functions of conventional gateways.

In particular, it might be too much to ask a NVE bas= ed gateway (especially Hypervisor based NVE) to

·        relay traffic off the virtual networks, i.e.= perform gateway function to reach destinations outside the local VNs, = ;

·        serve as IPSec gateway to external tra= ffic

·        perform NAT on the source virtual addresses,= or

·        relay traffic to a VN that doesn’t hav= e any hosts attached to the NVE.

The NVEs that are capable of performing inter-VN rep= laying are called “Distributed Gateway” in this document. (Note= : Inter-VN relaying capable NVE is a more accurate term). =

The NVO3 architecture should support distributed gat= eways, at least allowing some NVEs, if not all, supporting the inter-VN rel= aying function, especially when both source and destination are attached to= the same NVE. Such support requires the NVO3 control protocols include mechanisms for the maintenance and dist= ribution of the inter-VN policy information to the NVEs that are capable of= performing inter-VN communications.

<= /p>

There are many emails on the list with regard to the= necessity of having NVE<->NVE control plane protocol. All those emai= ls discussion warrants a subsection under Section 4 to explain why/how the = consequence of not having NVE<->NVE control plane protocol is a minor issue (or not worth addressing) in the environme= nt addressed by NVO3. Here is my suggested text:

4.4 Is it necessary to have Inter-NVE control pla= ne protocol? (Suggested new sub-section)

There could be various reasons, link failure, node f= ailure, or others, causing egress NVEs not reachable. Without any NVE<-&= gt;NVE control plane protocol, the ingress NVE is not aware of the reachabi= lity of egress NVE causing encapsulated packets to dropped somewhere in the underlay network.

If most TSes are only attached to a single NVE= and traffic to NVEs are not aggregated flows, then the NVE-NVE control pla= ne protocol doesn’t provide any benefits.   Under this envi= ronment, the difference between having “NVE-NVE control protocol" is whether the packets being dropped at the Ingress NVE or = somewhere in the underlay network when egress NVE is not reachable.

In data center environment where most communications= are among applications, most likely a source will not send more packets wi= thout acknowledgment from the destination. Then the impact of where the pac= ket is dropped is not that big.

However, in an env= ironment where TSes are connected to multiple NVEs, then it might be worthw= hile to consider the Inter-NVE control plane protocol, so that ingress NVE = can choose different egress NVE for a given target.

Thanks for considering my suggested text.

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F645C1BA4Fdfweml509mbxchi_-- From narten@us.ibm.com Mon Nov 18 13:25:59 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0191ADFD9 for ; Mon, 18 Nov 2013 13:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSnDLNCcLMMd for ; Mon, 18 Nov 2013 13:25:58 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by ietfa.amsl.com (Postfix) with ESMTP id 644B91AC7F1 for ; Mon, 18 Nov 2013 13:25:58 -0800 (PST) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 18 Nov 2013 14:25:52 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 18 Nov 2013 14:25:50 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 583AD19D8042 for ; Mon, 18 Nov 2013 14:25:45 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08025.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAIJO3Vg27721826 for ; Mon, 18 Nov 2013 20:24:03 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAILPoNB006537 for ; Mon, 18 Nov 2013 14:25:50 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-40-233.mts.ibm.com [9.65.40.233]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAILPnDf006460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Nov 2013 14:25:49 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAILPmPG008834 for ; Mon, 18 Nov 2013 16:25:48 -0500 Message-Id: <201311182125.rAILPmPG008834@cichlid.raleigh.ibm.com> From: Thomas Narten To: nvo3@ietf.org Date: Mon, 18 Nov 2013 16:25:48 -0500 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13111821-1344-0000-0000-0000035A41E2 Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:26:00 -0000 There has been some discussion on the list about whether or not to have a combined L2/L3 service. Here is proposed text for the architecture document: A virtual network can also provide a combined L2 and L3 service to tenants. In such cases, a tenant sends and receives both L2 and L3 packets. An NVE recieving packets from a TS determines the type of service to be applied to the packet on a per-packet basis as indicated by the packet's destination MAC address as provided by the TS. If the MAC address corresponds to that of an L3 router (as determined by the NVE), traffic is given L3 semantics. Otherwise, the packet is given L2 service semantics. A combined L2/L3 service presents no special considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. This text would go at the end of Section 3.1 "VN Service (L2 and L3)". Make sense? Additional thinking behind this (taken from mail within the DT): > FWIW, I think that there are separate issues here. One is simply > describing what we mean by a combined L2/L3 service. That is what my > text was trying to do. The thinking is if the service definition is > clear and simple, supporting it in NVO3 is not a problem. I.e., it's > not really much different to provide a combined service than if you > offer an L2 or L3 service. And the service semantics for combined > L2/L3 are easy to understand and explain. That is goodness. :-) > > Whether and how it makes sense to have distributed gateways in a > combined service is a separate matter. What I'd like to be able to do > here (if we need to say anything at all) is be able to say that if a > distributed GW makes sense for L2 service, then having an L2 > distributed GW for the L2 traffic would make sense in the combined > service case too. Ditto for L3 service. > > A key point is that having a combined service is pretty much the same > as taking the two separate L2 and L3 services and combining them into > one implementation. There is nothing really "special" about this that > would complicate the overall architecture. Where we can easily get > into trouble is if we start defining a combined service as has special > cases that have to be dealt with that don't appear when you have only > L2 or only L3 service semantics. Thomas From farinacci@gmail.com Mon Nov 18 14:06:28 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB451AE5EA for ; Mon, 18 Nov 2013 14:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZBhEhbfwnmK for ; Mon, 18 Nov 2013 14:06:26 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1FD1AE28E for ; Mon, 18 Nov 2013 14:06:26 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id up15so2615583pbc.24 for ; Mon, 18 Nov 2013 14:06:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h8ptvJpjEN20lAOx6CfSjjcCrc2/j0Dab8FiQa3fE7Y=; b=IfT28zFPDsvLchfH45FVTvbbMUdGN/44PidbGwMo72KIuHDOTSgcNBTcZr1i+p9BDR xHFJkUMJAhLQq2nwOGQ3US0bAvWYIhBuEmEazygNCv1B/hgOz+hpOK4gbtNGPM40Ih7a npHHgxoSdJdfms7HdZdDK1vt2WyWhZRY7i+0ZrQ2X15pLyfU7jb273FfnFOzic2og8d/ Nn5Hsp6lUPJwb4QgbTejjYQrsohr2If42IzxFY7x4/hlBhWpwUY29FKr7kc0yNEX0Jjs 1yogaiPpqTv9ayXTKQ67fCoE4geF6yfVUN1FbaPTDh7EpBKGOtUxDxdAUr0eMEBhRnus TE5Q== X-Received: by 10.68.125.226 with SMTP id mt2mr15639512pbb.115.1384812380616; Mon, 18 Nov 2013 14:06:20 -0800 (PST) Received: from [172.20.10.3] (mobile-166-137-176-228.mycingular.net. [166.137.176.228]) by mx.google.com with ESMTPSA id ka3sm25704084pbc.32.2013.11.18.14.06.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Nov 2013 14:06:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <1ba9bd6e64674f978c49b4c9abcddd77@BL2PR05MB082.namprd05.prod.outlook.com> Date: Mon, 18 Nov 2013 14:06:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <53EF8E84-8DB9-4135-A5F3-68FE3BA739AB@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> <8E3C9080-FB3E-4385-9714-AD61BCB09C34@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C080AD@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C0818C@dfweml509-mbx.china.huawei.com> <6CC52EB3-22E4-4E41-815B-3D76B6386681@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C1B6A6@dfweml509-mbx.china.huawei.com>, <376EC087-9596-4534-988E-1E611A596B54@gmail.com> <1ba9bd6e64674f978c49b4c9abcddd77@BL2PR05MB082.namprd05.prod.outlook.com> To: Ken Gray X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" , "Yves Hertoghs $yhertogh$" , Lucy Yong , Linda Dunbar Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 22:06:28 -0000 > Unless it's built at a lower layer than a piggy-back app, it's going = to be a scale monster (IMO, if you plan for success, then ultimately you = have highly connected NVEs - hello scale monster). Something like CFM = for overlays (logical ethernet, logical continuity check built into your = header as a special packet type, punt to momma NVE process ...not some = cousin, etc?)? =3D8^) Definitely agree Ken. See LISP echo-noncing. I pulled some text out of = RFC 6830 and pasted below. Dino ------ 6.3.1. Echo Nonce Algorithm When data flows bidirectionally between Locators from different sites, a data-plane mechanism called "nonce echoing" can be used to determine reachability between an ITR and ETR. When an ITR wants to solicit a nonce echo, it sets the N- and E-bits and places a 24-bit nonce [RFC4086] in the LISP header of the next encapsulated data packet. When this packet is received by the ETR, the encapsulated packet is forwarded as normal. When the ETR next sends a data packet to the ITR, it includes the nonce received earlier with the N-bit set and E-bit cleared. The ITR sees this "echoed nonce" and knows that the path to and from the ETR is up. The ITR will set the E-bit and N-bit for every packet it sends while in the echo-nonce-request state. The time the ITR waits to process the echoed nonce before it determines the path is unreachable is variable and is a choice left for the implementation. If the ITR is receiving packets from the ETR but does not see the nonce echoed while being in the echo-nonce-request state, then the path to the ETR is unreachable. This decision may be overridden by other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR may both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo nonce requests are sent is an implementation-specific setting. However, when an ITR is in the echo-nonce-request state, it can echo the ETR's nonce in the next set of packets that it encapsulates and subsequently continue sending echo-nonce-request packets. This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site may not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may erroneously consider the Locator unreachable. An ITR SHOULD only set the E-bit in an encapsulated data packet when it knows the ETR is enabled for echo-noncing. This is conveyed by the E-bit in the Map-Reply message. Note that other Locator reachability mechanisms are being researched and can be used to compliment or even override the echo nonce algorithm. See the next section for an example of control-plane probing. ------ From xuxiaohu@huawei.com Mon Nov 18 18:21:27 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155691ADFFA for ; Mon, 18 Nov 2013 18:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.426 X-Spam-Level: X-Spam-Status: No, score=-4.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 517Bct_vLwOP for ; Mon, 18 Nov 2013 18:21:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE9AE1ACC85 for ; Mon, 18 Nov 2013 18:21:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYB17512; Tue, 19 Nov 2013 02:21:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 02:21:10 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 02:21:14 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 10:21:03 +0800 From: Xuxiaohu To: "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5FWZFCIHY2yGjUOI9mnuyBT+AZor0vqw Date: Tue, 19 Nov 2013 02:21:02 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08234259@NKGEML512-MBS.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Lucy yong Subject: [nvo3] =?utf-8?b?562U5aSNOiAgTm8gbmVlZCBmb3IgTlZFLU5WRSBjb250cm9s?= =?utf-8?q?_plane_=5Bwas_Re=3A_Poll_for=09WG=09adoption_and_IPR_check_for_?= =?utf-8?q?draft-narten-nvo3-arch-01=2Etxt?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 02:21:27 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IG52bzMtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoDQo+IExBU1NFUlJF LCBNQVJDIChNQVJDKQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTPlubQxMeaciDE45pelIDE5OjU4DQo+ IOaUtuS7tuS6ujogVGhvbWFzIE5hcnRlbjsgWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpDQo+IOaK hOmAgTogbnZvM0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+IOS4u+mimDogUmU6IFtudm8zXSBObyBu ZWVkIGZvciBOVkUtTlZFIGNvbnRyb2wgcGxhbmUgW3dhcyBSZTogUG9sbCBmb3IgV0cNCj4gYWRv cHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCj4g DQo+IFRob21hcywNCj4gDQo+IFRoZSB3YXkgdGhhdCB5b3UgaGF2ZSBwaHJhc2VkIHRoaXMgc2Vu dGVuY2UgaXMgY29uZnVzaW5nIGFuZCBuZWVkcw0KPiBjbGFyaWZpY2F0aW9uLg0KPiANCj4gVmFy aW91cyBjb250cm9sIHByb3RvY29scyBjYW4gYmUgdXNlZCBiZXR3ZWVuIE5WRXMsIGFzIHlvdSBp bmRpY2F0ZWQuDQo+IA0KPiBJZiB5b3UgbWVhbnQgdG8gc2F5IHRoYXQgdGhlcmUgaXMgbm8gbmVl ZCBmb3IgTlZFcyB0byBleGNoYW5nZSBhZGRyZXNzIG1hcHBpbmcNCj4gaW5mb3JtYXRpb24gYmV0 d2VlbiB0aGVtc2VsdmVzLCB0aGlzIGlzIGFsc28gZGViYXRhYmxlLg0KPiBBbiBleHRlcm5hbCBO VkEgZm9yIHN1Y2ggYSBmdW5jdGlvbiBpcyBub3QgYWx3YXlzIHJlcXVpcmVkIGluIG52bzMuIFdo ZW4gdGhlDQo+IE5WQSBhZGRyZXNzIG1hcHBpbmcgZnVuY3Rpb24gaXMgY29sb2NhdGVkIHdpdGgg YW4gTlZFLCBOVkVzIGFwcGVhciBhcw0KPiBleGNoYW5naW5nIGFkZHJlc3MgbWFwcGluZyBpbmZv cm1hdGlvbiAoanVzdCBsb29raW5nIGF0IHRoZSB3aXJlKS4gSUdQcyB3aXRoaW4NCj4gTlZFcyBh bHNvIGV4Y2hhbmdlIHRvcG9sb2dpY2FsL2FkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbi4NCg0K RnVsbHkgYWdyZWUuDQoNClhpYW9odQ0KDQo+IE1hcmMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpudm8z LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9mIFRob21hcyBOYXJ0ZW4NCj4gPiBT ZW50OiBGcmlkYXksIE5vdmVtYmVyIDE1LCAyMDEzIDExOjE5IFBNDQo+ID4gVG86IFl2ZXMgSGVy dG9naHMgKHloZXJ0b2doKQ0KPiA+IENjOiBudm8zQGlldGYub3JnOyBMdWN5IHlvbmcNCj4gPiBT dWJqZWN0OiBbbnZvM10gTm8gbmVlZCBmb3IgTlZFLU5WRSBjb250cm9sIHBsYW5lIFt3YXMgUmU6 DQo+ID4gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFydGVu LW52bzMtYXJjaC0wMS50eHQNCj4gPg0KPiA+IE5WTzMgZG9lcyBub3QgbmVlZCBhbiBOVkUgdG8g TlZFIGNvbnRyb2wgcHJvdG9jb2wuDQo+ID4NCj4gPiBDYWxsaW5nIHRoaXMgb3V0IGV4cGxpY2l0 bHksIGFzIGl0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgY3VycmVudA0KPiA+IGFyY2hpdGVjdHVy ZSBkb2N1bWVudC4gVGhlcmUgaXMgbm8gbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sDQo+ ID4gcHJvdG9jb2wsIGZvciB0aGUgcHVycG9zZSBvZiBtYWludGFpbmluZy9wb3B1bGF0aW5nIHRo ZSBtYXBwaW5nDQo+ID4gdGFibGVzLiBUaGVyZSBtYXkgd2VsbCBiZSBpbnRlcmFjdGlvbnMgYmV0 d2VlbiBOVkVzLCBzdWNoIGFzIHNldHRpbmcNCj4gPiB1cCB0dW5uZWxzLCBjcmVhdGluZyBzZWN1 cml0eSBhc3NvY2lhdGlvbnMgZm9yIHByb3RlY3RpbmcgZGF0YSBwbGFuZQ0KPiA+IHRyYWZmaWMs IG9yIHByb3ZpZGluZyBlcnJvciBpbmRpY2F0aW9ucyAoZS5nLiwgZXF1aXZhbGVudCBvZiBJQ01Q ICJUUw0KPiA+IHVucmVhY2hhYmxlIiByZXNwb25zZXMpLg0KPiA+DQo+ID4gSWYgZm9sayBkaXNh Z3JlZSwgbm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIGhhdmUgdGhhdCBjb252ZXJzYXRpb24u DQo+ID4NCj4gPiAiWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpIiA8eWhlcnRvZ2hAY2lzY28uY29t PiB3cml0ZXM6DQo+ID4NCj4gPiA+ID4+IEkgZGlzYWdyZWUgd2l0aCB0aGUgbmVlZCBmb3IgYW4g TlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPiA+ID4NCj4gPiA+ID4gW0x1Y3ldIGRvIHlvdSB0 aGluayB3ZSBuZWVkIE5WRS1OVkUgY29udHJvbCBwbGFuZT8gSQ0KPiA+IGRvbsOi4oKs4oSidCB0 aGluaw0KPiA+ID4gPiB0aGlzIGlzIHdoYXQgeW91IG1lYW4gZnJvbSB0aGUgZm9sbG93aW5nIHN0 YXRlbWVudC4NCj4gPiA+DQo+ID4gPiBObyB3ZSBkb250IG5lZWQgYW4gTlZFIHRvIE5WRSBjb250 cm9sIHBsYW5lLg0KPiA+ID4NCj4gPiA+ID4+IFRoYXQgZG9lc24ndCBtZWFuIHRoYXQgeW91IGNh bid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUNCj4gPiA+ID4+IGRpc3RyaWJ1dGVkIE5WQSB3 aXRoIGV2ZXJ5IE5WRSwgd2hpY2ggaXMgdGhlIG1vZGVsIHRoYXQgZS5nLg0KPiA+ID4gPj4gQkdQ L0wzVlBOIG9yIElTSVMvVFJJTEwgdXNlcy4NCj4gPiA+DQo+ID4gPiA+IFtMdWN5XSBBZ3JlZWQu IE5WQSBjYW4gY29sbG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBvciBlbnRpcmUpLg0KPiA+ID4N Cj4gPiA+IEFuZCBhcyBhIHJlc3VsdCB0aGVyZSBpcyBvbmx5IGEgbmVlZCBmb3IgYSBjb250cm9s IHBsYW5lDQo+ID4gYmV0d2VlbiB0aGUNCj4gPiA+IE5WRSBmdW5jdGlvbiBhbmQgdGhlIE5WQSBm dW5jdGlvbi4NCj4gPg0KPiA+IFRob21hcw0KPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZv M0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMN Cg== From Garg.Pankaj@microsoft.com Tue Nov 19 04:37:16 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B49F1ADF57 for ; Tue, 19 Nov 2013 04:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mY9So-3F7KU for ; Tue, 19 Nov 2013 04:37:13 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1361ADF44 for ; Tue, 19 Nov 2013 04:37:13 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 12:36:59 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.123]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 12:36:53 +0000 From: Pankaj Garg To: Ken Gray , "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5JPrlHpShPjXtkubUQNzyqxIOposfQAg Date: Tue, 19 Nov 2013 12:36:52 +0000 Message-ID: References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> In-Reply-To: <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.62.209.16] x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(51704005)(13464003)(189002)(199002)(77096001)(74876001)(76786001)(4396001)(56816003)(49866001)(87266001)(47736001)(74316001)(63696002)(81816001)(50986001)(74706001)(47976001)(15975445006)(74366001)(81686001)(76796001)(47446002)(74502001)(1941001)(65816001)(224303002)(81542001)(69226001)(76576001)(224313003)(81342001)(80022001)(2656002)(66066001)(53806001)(19580395003)(80976001)(87936001)(77982001)(31966008)(561944002)(59766001)(56776001)(51856001)(79102001)(54356001)(83322001)(46102001)(83072001)(74662001)(54316002)(33646001)(85306002)(19580405001)(76482001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:125.62.209.16; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:37:16 -0000 TlZFLU5WRSBjb250cm9sIHBsYW5lIGlzIG5lZWRlZCBmb3Igb3BlcmF0aW9ucyB0aGF0IGRvbid0 IG5lY2Vzc2FyaWx5IG5lZWQgTlZBIGludGVyYWN0aW9uIG9yIHdoZXJlIE5WRS1OVkUgaW50ZXJh Y3Rpb24gY2FuIHByb3ZpZGUgYmV0dGVyIHBlcmZvcm1hbmNlLiANCg0KRm9yIGV4YW1wbGUsIGlm IHRoZSAibWFwcGluZ3MiIGFyZSBzdGFsZSBvbiBhbiBOVkUsIHRoZW4gdGhlIHJlY2VpdmVyIE5W RSBjYW4gc2VuZCBhIGNvbnRyb2wgcGxhbmUgbWVzc2FnZSB0byB0aGUgc2VuZGVyIE5WRSB0byB1 cGRhdGUgaXRzIG1hcHBpbmdzLiBUaGlzIGNhbiBoYXBwZW4gZHVlIHRvIGV2ZW50cyB3aGVyZSB0 aGUgVk0gbGl2ZSBtaWdyYXRlZCBmcm9tIG9uZSBob3N0IHRvIGFub3RoZXIgYnV0IHRoZSBzZW5k ZXIgTlZFIGhhcyBzdGFsZSBtYXBwaW5ncyBkdWUgdG8gZGVsYXkgaW4gZ2V0dGluZyB0aG9zZSBt YXBwaW5ncyB1cGRhdGVkIHZpYSBOVkEuIFRoaW5rIG9mIHRoaXMgYXMgYSBoaW50IGZvciBjYWNo ZSBmbHVzaCBmcm9tIHRoZSByZWNlaXZlciBOVkUgdG8gdGhlIHNlbmRlciBOVkUuIA0KDQpUaGUg Y29udHJvbCBwbGFuZSBiZXR3ZWVuIE5WRS1OVkUgY2FuIGFsc28gYmUgdXNlZCBmb3IgcHJvdG9j b2wgbmVnb3RpYXRpb24gaW4gY2FzZSBvZiBtdWx0aS1wcm90b2NvbCBzdXBwb3J0IGF0IE5WRS4N Cg0KUGFua2FqDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBudm8zIFttYWls dG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VuIEdyYXkNClNlbnQ6IFR1 ZXNkYXksIE5vdmVtYmVyIDE5LCAyMDEzIDEyOjU1IEFNDQpUbzogTEFTU0VSUkUsIE1BUkMgKE1B UkMpOyBUaG9tYXMgTmFydGVuOyBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCkNCkNjOiBudm8zQGll dGYub3JnOyBMdWN5IHlvbmcNClN1YmplY3Q6IFJlOiBbbnZvM10gTm8gbmVlZCBmb3IgTlZFLU5W RSBjb250cm9sIHBsYW5lIFt3YXMgUmU6IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hl Y2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNCkkgZG9uJ3QgdGhpbmsgdGhl IGxvZ2ljYWwgYXNzb2NpYXRpb24gb2YgdGhlIE5WQSB3aXRoIGFuIE5WRSBuZWdhdGVzIFRob21h cyBiYXNpYyBwb2ludC4gIFRoZSBrZXkgd29yZCB5b3UgdXNlIGhlcmUgaXMgImFwcGVhcnMiIC4u LiBpbiB0aGUgZW5kLCBpdCdzIG5vdCB0aGUgTlZFIHRoYXQgb3RoZXIgTlZFcyBhcmUgZXhjaGFu Z2luZyBtYXBwaW5nIGluZm9ybWF0aW9uIHdpdGgsIGl0IGlzIHRoZSBOVkEgdGhhdCBpcyBjby1s b2NhdGVkLg0KDQorMSBmb3IgVGhvbWFzIHByb3Bvc2FsLiAgWUVTLCB5b3UgY2FuIG1ha2UgaXQg bW9yZSBleHBsaWNpdCBpbiB0aGUgYXJjaGl0ZWN0dXJlIHRoYXQgIm1hcHBpbmciIGlzIHdoYXQg eW91IGFyZSB0YWxraW5nIGFib3V0IGluc3RlYWQgb2YgdGhlIGdlbmVyaWMgImNvbnRyb2wiLg0K DQpXZSBjYW4gYmVhdCBOVkUtTlZFIGxpdmVsaW5lc3MgdG8gZGVhdGggd2l0aCBvdGhlciB0cnVu Y2hlb25zLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog bnZvMy1ib3VuY2VzQGlldGYub3JnIDxudm8zLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBMQVNTRVJSRSwgTUFSQyAoTUFSQykgPG1hcmMubGFzc2VycmVAYWxjYXRlbC1sdWNlbnQuY29t Pg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOCwgMjAxMyA2OjU4IEFNDQpUbzogVGhvbWFzIE5h cnRlbjsgWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpDQpDYzogbnZvM0BpZXRmLm9yZzsgTHVjeSB5 b25nDQpTdWJqZWN0OiBSZTogW252bzNdIE5vIG5lZWQgZm9yIE5WRS1OVkUgY29udHJvbCBwbGFu ZSBbd2FzIFJlOiBQb2xsIGZvciBXRyAgICAgIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRy YWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQoNClRob21hcywNCg0KVGhlIHdheSB0aGF0IHlv dSBoYXZlIHBocmFzZWQgdGhpcyBzZW50ZW5jZSBpcyBjb25mdXNpbmcgYW5kIG5lZWRzIGNsYXJp ZmljYXRpb24uDQoNClZhcmlvdXMgY29udHJvbCBwcm90b2NvbHMgY2FuIGJlIHVzZWQgYmV0d2Vl biBOVkVzLCBhcyB5b3UgaW5kaWNhdGVkLg0KDQpJZiB5b3UgbWVhbnQgdG8gc2F5IHRoYXQgdGhl cmUgaXMgbm8gbmVlZCBmb3IgTlZFcyB0byBleGNoYW5nZSBhZGRyZXNzIG1hcHBpbmcgaW5mb3Jt YXRpb24gYmV0d2VlbiB0aGVtc2VsdmVzLCB0aGlzIGlzIGFsc28gZGViYXRhYmxlLg0KQW4gZXh0 ZXJuYWwgTlZBIGZvciBzdWNoIGEgZnVuY3Rpb24gaXMgbm90IGFsd2F5cyByZXF1aXJlZCBpbiBu dm8zLiBXaGVuIHRoZSBOVkEgYWRkcmVzcyBtYXBwaW5nIGZ1bmN0aW9uIGlzIGNvbG9jYXRlZCB3 aXRoIGFuIE5WRSwgTlZFcyBhcHBlYXIgYXMgZXhjaGFuZ2luZyBhZGRyZXNzIG1hcHBpbmcgaW5m b3JtYXRpb24gKGp1c3QgbG9va2luZyBhdCB0aGUgd2lyZSkuIElHUHMgd2l0aGluIE5WRXMgYWxz byBleGNoYW5nZSB0b3BvbG9naWNhbC9hZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24uDQoNCk1h cmMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBudm8zLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2Yg VGhvbWFzIE5hcnRlbg0KPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE1LCAyMDEzIDExOjE5IFBN DQo+IFRvOiBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCkNCj4gQ2M6IG52bzNAaWV0Zi5vcmc7IEx1 Y3kgeW9uZw0KPiBTdWJqZWN0OiBbbnZvM10gTm8gbmVlZCBmb3IgTlZFLU5WRSBjb250cm9sIHBs YW5lIFt3YXMgUmU6DQo+IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRy YWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+DQo+IE5WTzMgZG9lcyBub3QgbmVlZCBhbiBO VkUgdG8gTlZFIGNvbnRyb2wgcHJvdG9jb2wuDQo+DQo+IENhbGxpbmcgdGhpcyBvdXQgZXhwbGlj aXRseSwgYXMgaXQgaXMgY29uc2lzdGVudCB3aXRoIHRoZSBjdXJyZW50IA0KPiBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIGFuIE5WRSB0byBOVkUgY29udHJvbCAN Cj4gcHJvdG9jb2wsIGZvciB0aGUgcHVycG9zZSBvZiBtYWludGFpbmluZy9wb3B1bGF0aW5nIHRo ZSBtYXBwaW5nIA0KPiB0YWJsZXMuIFRoZXJlIG1heSB3ZWxsIGJlIGludGVyYWN0aW9ucyBiZXR3 ZWVuIE5WRXMsIHN1Y2ggYXMgc2V0dGluZyANCj4gdXAgdHVubmVscywgY3JlYXRpbmcgc2VjdXJp dHkgYXNzb2NpYXRpb25zIGZvciBwcm90ZWN0aW5nIGRhdGEgcGxhbmUgDQo+IHRyYWZmaWMsIG9y IHByb3ZpZGluZyBlcnJvciBpbmRpY2F0aW9ucyAoZS5nLiwgZXF1aXZhbGVudCBvZiBJQ01QICJU UyANCj4gdW5yZWFjaGFibGUiIHJlc3BvbnNlcykuDQo+DQo+IElmIGZvbGsgZGlzYWdyZWUsIG5v dyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBoYXZlIHRoYXQgY29udmVyc2F0aW9uLg0KPg0KPiAi WXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpIiA8eWhlcnRvZ2hAY2lzY28uY29tPiB3cml0ZXM6DQo+ DQo+ID4gPj4gSSBkaXNhZ3JlZSB3aXRoIHRoZSBuZWVkIGZvciBhbiBOVkUgdG8gTlZFIGNvbnRy b2wgcGxhbmUuDQo+ID4NCj4gPiA+IFtMdWN5XSBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZF IGNvbnRyb2wgcGxhbmU/IEkNCj4gZG9uw6LigqzihKJ0IHRoaW5rDQo+ID4gPiB0aGlzIGlzIHdo YXQgeW91IG1lYW4gZnJvbSB0aGUgZm9sbG93aW5nIHN0YXRlbWVudC4NCj4gPg0KPiA+IE5vIHdl IGRvbnQgbmVlZCBhbiBOVkUgdG8gTlZFIGNvbnRyb2wgcGxhbmUuDQo+ID4NCj4gPiA+PiBUaGF0 IGRvZXNuJ3QgbWVhbiB0aGF0IHlvdSBjYW4ndCBjb2xvY2F0ZSBhIHBvcnRpb24gb2YgdGhlIA0K PiA+ID4+IGRpc3RyaWJ1dGVkIE5WQSB3aXRoIGV2ZXJ5IE5WRSwgd2hpY2ggaXMgdGhlIG1vZGVs IHRoYXQgZS5nLg0KPiA+ID4+IEJHUC9MM1ZQTiBvciBJU0lTL1RSSUxMIHVzZXMuDQo+ID4NCj4g PiA+IFtMdWN5XSBBZ3JlZWQuIE5WQSBjYW4gY29sbG9jYXRlIHcvIE5WRS4gKHBhcnRpYWxseSBv ciBlbnRpcmUpLg0KPiA+DQo+ID4gQW5kIGFzIGEgcmVzdWx0IHRoZXJlIGlzIG9ubHkgYSBuZWVk IGZvciBhIGNvbnRyb2wgcGxhbmUNCj4gYmV0d2VlbiB0aGUNCj4gPiBOVkUgZnVuY3Rpb24gYW5k IHRoZSBOVkEgZnVuY3Rpb24uDQo+DQo+IFRob21hcw0KPg0KPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGluZyBsaXN0DQpudm8zQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52bzMgbWFpbGlu ZyBsaXN0DQpudm8zQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCg== From linda.dunbar@huawei.com Tue Nov 19 08:09:35 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3951A1AE072 for ; Tue, 19 Nov 2013 08:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.726 X-Spam-Level: X-Spam-Status: No, score=-3.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_33=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsRhtbeF4yG1 for ; Tue, 19 Nov 2013 08:09:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 40A991AE04C for ; Tue, 19 Nov 2013 08:09:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYB90376; Tue, 19 Nov 2013 16:09:25 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 16:09:14 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 16:09:22 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 08:09:12 -0800 From: Linda Dunbar To: Pankaj Garg , Ken Gray , "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5JPrlHpShPjXtkubUQNzyqxIOposfQAggAA67tA= Date: Tue, 19 Nov 2013 16:09:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:09:35 -0000 UGFua2FqLCANCg0KT2YgY291cnNlLCBOVkUtTlZFIHByb3RvY29sIGNhbiBhZGQgYmVuZWZpdHMs IGJ1dCBpdCBhbHNvIGFkZHMgY29zdC4gQSBnb29kIGRlc2lnbiBpcyBub3QgYWJvdXQgaWYgdGhl cmUgaXMgbm90aGluZyB0byBhZGQsIGJ1dCBhYm91dCBpZiB0aGVyZSBpcyBub3RoaW5nIHRoYXQg Y2FuIGJlIHJlbW92ZWQuIA0KSWYgbW9zdCBUU2VzIGFyZSBvbmx5IGF0dGFjaGVkIHRvIGEgc2lu Z2xlIE5WRSBhbmQgdHJhZmZpYyB0byBOVkVzIGFyZSBub3QgYWdncmVnYXRlZCBmbG93cywgdGhl biB0aGUgTlZFLU5WRSBjb250cm9sIHBsYW5lIHByb3RvY29sIGRvZXNu4oCZdCBwcm92aWRlIG11 Y2ggYmVuZWZpdHMuICAgVW5kZXIgdGhpcyBlbnZpcm9ubWVudCwgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiBoYXZpbmcg4oCcTlZFLU5WRSBjb250cm9sIHByb3RvY29sIiBpcyB3aGV0aGVyIHRoZSBw YWNrZXRzIGJlaW5nIGRyb3BwZWQgYXQgdGhlIEluZ3Jlc3MgTlZFIG9yIHNvbWV3aGVyZSBpbiB0 aGUgdW5kZXJsYXkgbmV0d29yayB3aGVuIGVncmVzcyBOVkUgaXMgbm90IHJlYWNoYWJsZS4gIA0K SW4gZGF0YSBjZW50ZXIgZW52aXJvbm1lbnQgd2hlcmUgbW9zdCBjb21tdW5pY2F0aW9ucyBhcmUg YW1vbmcgYXBwbGljYXRpb25zLCBtb3N0IGxpa2VseSBhIHNvdXJjZSB3aWxsIG5vdCBzZW5kIG1v cmUgcGFja2V0cyB3aXRob3V0IGFja25vd2xlZGdtZW50IGZyb20gdGhlIGRlc3RpbmF0aW9uLiBU aGVuIHRoZSBpbXBhY3Qgb2Ygd2hlcmUgdGhlIHBhY2tldCBpcyBkcm9wcGVkIGlzIG5vdCB0aGF0 IGJpZy4NCiANClRoZXJlZm9yZSwgSSB0aGluayBpdCBpcyB3b3J0aHdoaWxlIHRvIGhhdmUgYSBz dWJzZWN0aW9uIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgdG8gZGVzY3JpYmUgdGhpcyB0 cmFkZS1vZmYuIEl0IGlzIG5vdCBjbGVhci1jdXQgIm11c3QgaGF2ZSIgb3IgIm11c3Qgbm90IGhh dmUiLiANCkhlcmUgaXMgbXkgc3VnZ2VzdGVkIHN1YnNlY3Rpb246DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo0LjQgSXMgaXQgbmVjZXNzYXJ5 IHRvIGhhdmUgSW50ZXItTlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2w/IChTdWdnZXN0ZWQgbmV3 IHN1Yi1zZWN0aW9uKQ0KVGhlcmUgY291bGQgYmUgdmFyaW91cyByZWFzb25zLCBsaW5rIGZhaWx1 cmUsIG5vZGUgZmFpbHVyZSwgb3Igb3RoZXJzLCBjYXVzaW5nIGVncmVzcyBOVkVzIG5vdCByZWFj aGFibGUuIFdpdGhvdXQgYW55IE5WRTwtPk5WRSBjb250cm9sIHBsYW5lIHByb3RvY29sLCB0aGUg aW5ncmVzcyBOVkUgaXMgbm90IGF3YXJlIG9mIHRoZSByZWFjaGFiaWxpdHkgb2YgZWdyZXNzIE5W RSBjYXVzaW5nIGVuY2Fwc3VsYXRlZCBwYWNrZXRzIHRvIGRyb3BwZWQgc29tZXdoZXJlIGluIHRo ZSB1bmRlcmxheSBuZXR3b3JrLiANCiBJZiBtb3N0IFRTZXMgYXJlIG9ubHkgYXR0YWNoZWQgdG8g YSBzaW5nbGUgTlZFIGFuZCB0cmFmZmljIHRvIE5WRXMgYXJlIG5vdCBhZ2dyZWdhdGVkIGZsb3dz LCB0aGVuIHRoZSBOVkUtTlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgZG9lc27igJl0IHByb3Zp ZGUgbXVjaCBiZW5lZml0cy4gICBVbmRlciB0aGlzIGVudmlyb25tZW50LCB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIGhhdmluZyDigJxOVkUtTlZFIGNvbnRyb2wgcHJvdG9jb2wiIGlzIHdoZXRoZXIg dGhlIHBhY2tldHMgYmVpbmcgZHJvcHBlZCBhdCB0aGUgSW5ncmVzcyBOVkUgb3Igc29tZXdoZXJl IGluIHRoZSB1bmRlcmxheSBuZXR3b3JrIHdoZW4gZWdyZXNzIE5WRSBpcyBub3QgcmVhY2hhYmxl LiAgDQpJbiBkYXRhIGNlbnRlciBlbnZpcm9ubWVudCB3aGVyZSBtb3N0IGNvbW11bmljYXRpb25z IGFyZSBhbW9uZyBhcHBsaWNhdGlvbnMsIG1vc3QgbGlrZWx5IGEgc291cmNlIHdpbGwgbm90IHNl bmQgbW9yZSBwYWNrZXRzIHdpdGhvdXQgYWNrbm93bGVkZ21lbnQgZnJvbSB0aGUgZGVzdGluYXRp b24uIFRoZW4gdGhlIGltcGFjdCBvZiB3aGVyZSB0aGUgcGFja2V0IGlzIGRyb3BwZWQgaXMgbm90 IHRoYXQgYmlnLiANCkhvd2V2ZXIsIGluIGFuIGVudmlyb25tZW50IHdoZXJlIFRTZXMgYXJlIGNv bm5lY3RlZCB0byBtdWx0aXBsZSBOVkVzLCB0aGVuIGl0IG1pZ2h0IGJlIHdvcnRod2hpbGUgdG8g Y29uc2lkZXIgdGhlIEludGVyLU5WRSBjb250cm9sIHBsYW5lIHByb3RvY29sLCBzbyB0aGF0IGlu Z3Jlc3MgTlZFIGNhbiBjaG9vc2UgZGlmZmVyZW50IGVncmVzcyBOVkUgZm9yIGEgZ2l2ZW4gdGFy Z2V0Lg0KDQoNCkxpbmRhIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IG52bzMgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYW5rYWog R2FyZw0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxOSwgMjAxMyA2OjM3IEFNDQo+IFRvOiBL ZW4gR3JheTsgTEFTU0VSUkUsIE1BUkMgKE1BUkMpOyBUaG9tYXMgTmFydGVuOyBZdmVzIEhlcnRv Z2hzDQo+ICh5aGVydG9naCkNCj4gQ2M6IG52bzNAaWV0Zi5vcmc7IEx1Y3kgeW9uZw0KPiBTdWJq ZWN0OiBSZTogW252bzNdIE5vIG5lZWQgZm9yIE5WRS1OVkUgY29udHJvbCBwbGFuZSBbd2FzIFJl OiBQb2xsIGZvcg0KPiBXRyBhZG9wdGlvbiBhbmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4t bnZvMy1hcmNoLTAxLnR4dA0KPiANCj4gTlZFLU5WRSBjb250cm9sIHBsYW5lIGlzIG5lZWRlZCBm b3Igb3BlcmF0aW9ucyB0aGF0IGRvbid0IG5lY2Vzc2FyaWx5DQo+IG5lZWQgTlZBIGludGVyYWN0 aW9uIG9yIHdoZXJlIE5WRS1OVkUgaW50ZXJhY3Rpb24gY2FuIHByb3ZpZGUgYmV0dGVyDQo+IHBl cmZvcm1hbmNlLg0KPiANCj4gRm9yIGV4YW1wbGUsIGlmIHRoZSAibWFwcGluZ3MiIGFyZSBzdGFs ZSBvbiBhbiBOVkUsIHRoZW4gdGhlIHJlY2VpdmVyDQo+IE5WRSBjYW4gc2VuZCBhIGNvbnRyb2wg cGxhbmUgbWVzc2FnZSB0byB0aGUgc2VuZGVyIE5WRSB0byB1cGRhdGUgaXRzDQo+IG1hcHBpbmdz LiBUaGlzIGNhbiBoYXBwZW4gZHVlIHRvIGV2ZW50cyB3aGVyZSB0aGUgVk0gbGl2ZSBtaWdyYXRl ZCBmcm9tDQo+IG9uZSBob3N0IHRvIGFub3RoZXIgYnV0IHRoZSBzZW5kZXIgTlZFIGhhcyBzdGFs ZSBtYXBwaW5ncyBkdWUgdG8gZGVsYXkNCj4gaW4gZ2V0dGluZyB0aG9zZSBtYXBwaW5ncyB1cGRh dGVkIHZpYSBOVkEuIFRoaW5rIG9mIHRoaXMgYXMgYSBoaW50IGZvcg0KPiBjYWNoZSBmbHVzaCBm cm9tIHRoZSByZWNlaXZlciBOVkUgdG8gdGhlIHNlbmRlciBOVkUuDQo+IA0KPiBUaGUgY29udHJv bCBwbGFuZSBiZXR3ZWVuIE5WRS1OVkUgY2FuIGFsc28gYmUgdXNlZCBmb3IgcHJvdG9jb2wNCj4g bmVnb3RpYXRpb24gaW4gY2FzZSBvZiBtdWx0aS1wcm90b2NvbCBzdXBwb3J0IGF0IE5WRS4NCj4g DQo+IFBhbmthag0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbnZv MyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbiBHcmF5DQo+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDE5LCAyMDEzIDEyOjU1IEFNDQo+IFRvOiBMQVNTRVJS RSwgTUFSQyAoTUFSQyk7IFRob21hcyBOYXJ0ZW47IFl2ZXMgSGVydG9naHMgKHloZXJ0b2doKQ0K PiBDYzogbnZvM0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+IFN1YmplY3Q6IFJlOiBbbnZvM10gTm8g bmVlZCBmb3IgTlZFLU5WRSBjb250cm9sIHBsYW5lIFt3YXMgUmU6IFBvbGwgZm9yDQo+IFdHIGFk b3B0aW9uIGFuZCBJUFIgY2hlY2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+ IA0KPiBJIGRvbid0IHRoaW5rIHRoZSBsb2dpY2FsIGFzc29jaWF0aW9uIG9mIHRoZSBOVkEgd2l0 aCBhbiBOVkUgbmVnYXRlcw0KPiBUaG9tYXMgYmFzaWMgcG9pbnQuICBUaGUga2V5IHdvcmQgeW91 IHVzZSBoZXJlIGlzICJhcHBlYXJzIiAuLi4gaW4gdGhlDQo+IGVuZCwgaXQncyBub3QgdGhlIE5W RSB0aGF0IG90aGVyIE5WRXMgYXJlIGV4Y2hhbmdpbmcgbWFwcGluZw0KPiBpbmZvcm1hdGlvbiB3 aXRoLCBpdCBpcyB0aGUgTlZBIHRoYXQgaXMgY28tbG9jYXRlZC4NCj4gDQo+ICsxIGZvciBUaG9t YXMgcHJvcG9zYWwuICBZRVMsIHlvdSBjYW4gbWFrZSBpdCBtb3JlIGV4cGxpY2l0IGluIHRoZQ0K PiBhcmNoaXRlY3R1cmUgdGhhdCAibWFwcGluZyIgaXMgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJv dXQgaW5zdGVhZCBvZg0KPiB0aGUgZ2VuZXJpYyAiY29udHJvbCIuDQo+IA0KPiBXZSBjYW4gYmVh dCBOVkUtTlZFIGxpdmVsaW5lc3MgdG8gZGVhdGggd2l0aCBvdGhlciB0cnVuY2hlb25zLg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IG52bzMtYm91 bmNlc0BpZXRmLm9yZyA8bnZvMy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YNCj4gTEFT U0VSUkUsIE1BUkMgKE1BUkMpIDxtYXJjLmxhc3NlcnJlQGFsY2F0ZWwtbHVjZW50LmNvbT4NCj4g U2VudDogTW9uZGF5LCBOb3ZlbWJlciAxOCwgMjAxMyA2OjU4IEFNDQo+IFRvOiBUaG9tYXMgTmFy dGVuOyBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCkNCj4gQ2M6IG52bzNAaWV0Zi5vcmc7IEx1Y3kg eW9uZw0KPiBTdWJqZWN0OiBSZTogW252bzNdIE5vIG5lZWQgZm9yIE5WRS1OVkUgY29udHJvbCBw bGFuZSBbd2FzIFJlOiBQb2xsIGZvcg0KPiBXRyAgICAgIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sg Zm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+IA0KPiBUaG9tYXMsDQo+IA0KPiBU aGUgd2F5IHRoYXQgeW91IGhhdmUgcGhyYXNlZCB0aGlzIHNlbnRlbmNlIGlzIGNvbmZ1c2luZyBh bmQgbmVlZHMNCj4gY2xhcmlmaWNhdGlvbi4NCj4gDQo+IFZhcmlvdXMgY29udHJvbCBwcm90b2Nv bHMgY2FuIGJlIHVzZWQgYmV0d2VlbiBOVkVzLCBhcyB5b3UgaW5kaWNhdGVkLg0KPiANCj4gSWYg eW91IG1lYW50IHRvIHNheSB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yIE5WRXMgdG8gZXhjaGFu Z2UgYWRkcmVzcw0KPiBtYXBwaW5nIGluZm9ybWF0aW9uIGJldHdlZW4gdGhlbXNlbHZlcywgdGhp cyBpcyBhbHNvIGRlYmF0YWJsZS4NCj4gQW4gZXh0ZXJuYWwgTlZBIGZvciBzdWNoIGEgZnVuY3Rp b24gaXMgbm90IGFsd2F5cyByZXF1aXJlZCBpbiBudm8zLg0KPiBXaGVuIHRoZSBOVkEgYWRkcmVz cyBtYXBwaW5nIGZ1bmN0aW9uIGlzIGNvbG9jYXRlZCB3aXRoIGFuIE5WRSwgTlZFcw0KPiBhcHBl YXIgYXMgZXhjaGFuZ2luZyBhZGRyZXNzIG1hcHBpbmcgaW5mb3JtYXRpb24gKGp1c3QgbG9va2lu ZyBhdCB0aGUNCj4gd2lyZSkuIElHUHMgd2l0aGluIE5WRXMgYWxzbyBleGNoYW5nZSB0b3BvbG9n aWNhbC9hZGRyZXNzIG1hcHBpbmcNCj4gaW5mb3JtYXRpb24uDQo+IA0KPiBNYXJjDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbnZvMy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiBPZiBUaG9t YXMgTmFydGVuDQo+ID4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNSwgMjAxMyAxMToxOSBQTQ0K PiA+IFRvOiBZdmVzIEhlcnRvZ2hzICh5aGVydG9naCkNCj4gPiBDYzogbnZvM0BpZXRmLm9yZzsg THVjeSB5b25nDQo+ID4gU3ViamVjdDogW252bzNdIE5vIG5lZWQgZm9yIE5WRS1OVkUgY29udHJv bCBwbGFuZSBbd2FzIFJlOg0KPiA+IFBvbGwgZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hlY2sg Zm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+ID4NCj4gPiBOVk8zIGRvZXMgbm90 IG5lZWQgYW4gTlZFIHRvIE5WRSBjb250cm9sIHByb3RvY29sLg0KPiA+DQo+ID4gQ2FsbGluZyB0 aGlzIG91dCBleHBsaWNpdGx5LCBhcyBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGN1cnJlbnQN Cj4gPiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIGFuIE5WRSB0 byBOVkUgY29udHJvbA0KPiA+IHByb3RvY29sLCBmb3IgdGhlIHB1cnBvc2Ugb2YgbWFpbnRhaW5p bmcvcG9wdWxhdGluZyB0aGUgbWFwcGluZw0KPiA+IHRhYmxlcy4gVGhlcmUgbWF5IHdlbGwgYmUg aW50ZXJhY3Rpb25zIGJldHdlZW4gTlZFcywgc3VjaCBhcyBzZXR0aW5nDQo+ID4gdXAgdHVubmVs cywgY3JlYXRpbmcgc2VjdXJpdHkgYXNzb2NpYXRpb25zIGZvciBwcm90ZWN0aW5nIGRhdGEgcGxh bmUNCj4gPiB0cmFmZmljLCBvciBwcm92aWRpbmcgZXJyb3IgaW5kaWNhdGlvbnMgKGUuZy4sIGVx dWl2YWxlbnQgb2YgSUNNUCAiVFMNCj4gPiB1bnJlYWNoYWJsZSIgcmVzcG9uc2VzKS4NCj4gPg0K PiA+IElmIGZvbGsgZGlzYWdyZWUsIG5vdyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBoYXZlIHRo YXQgY29udmVyc2F0aW9uLg0KPiA+DQo+ID4gIll2ZXMgSGVydG9naHMgKHloZXJ0b2doKSIgPHlo ZXJ0b2doQGNpc2NvLmNvbT4gd3JpdGVzOg0KPiA+DQo+ID4gPiA+PiBJIGRpc2FncmVlIHdpdGgg dGhlIG5lZWQgZm9yIGFuIE5WRSB0byBOVkUgY29udHJvbCBwbGFuZS4NCj4gPiA+DQo+ID4gPiA+ IFtMdWN5XSBkbyB5b3UgdGhpbmsgd2UgbmVlZCBOVkUtTlZFIGNvbnRyb2wgcGxhbmU/IEkNCj4g PiBkb27DouKCrOKEonQgdGhpbmsNCj4gPiA+ID4gdGhpcyBpcyB3aGF0IHlvdSBtZWFuIGZyb20g dGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQuDQo+ID4gPg0KPiA+ID4gTm8gd2UgZG9udCBuZWVkIGFu IE5WRSB0byBOVkUgY29udHJvbCBwbGFuZS4NCj4gPiA+DQo+ID4gPiA+PiBUaGF0IGRvZXNuJ3Qg bWVhbiB0aGF0IHlvdSBjYW4ndCBjb2xvY2F0ZSBhIHBvcnRpb24gb2YgdGhlDQo+ID4gPiA+PiBk aXN0cmlidXRlZCBOVkEgd2l0aCBldmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUu Zy4NCj4gPiA+ID4+IEJHUC9MM1ZQTiBvciBJU0lTL1RSSUxMIHVzZXMuDQo+ID4gPg0KPiA+ID4g PiBbTHVjeV0gQWdyZWVkLiBOVkEgY2FuIGNvbGxvY2F0ZSB3LyBOVkUuIChwYXJ0aWFsbHkgb3Ig ZW50aXJlKS4NCj4gPiA+DQo+ID4gPiBBbmQgYXMgYSByZXN1bHQgdGhlcmUgaXMgb25seSBhIG5l ZWQgZm9yIGEgY29udHJvbCBwbGFuZQ0KPiA+IGJldHdlZW4gdGhlDQo+ID4gPiBOVkUgZnVuY3Rp b24gYW5kIHRoZSBOVkEgZnVuY3Rpb24uDQo+ID4NCj4gPiBUaG9tYXMNCj4gPg0KPiA+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFp bGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9udm8zDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0K PiBudm8zQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMw0K From Garg.Pankaj@microsoft.com Tue Nov 19 11:19:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE011AE199 for ; Tue, 19 Nov 2013 11:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_33=1, J_BACKHAIR_37=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh4Y3gEV7FOH for ; Tue, 19 Nov 2013 11:19:54 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0155.outbound.protection.outlook.com [207.46.163.155]) by ietfa.amsl.com (Postfix) with ESMTP id DE0FF1AE19A for ; Tue, 19 Nov 2013 11:19:53 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB126.namprd03.prod.outlook.com (10.242.36.21) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 19 Nov 2013 19:19:45 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.123]) with mapi id 15.00.0820.005; Tue, 19 Nov 2013 19:19:45 +0000 From: Pankaj Garg To: Linda Dunbar , Ken Gray , "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO5UG/UgfTZKAql0eiE6gpPnbXPpos6oiw Date: Tue, 19 Nov 2013 19:19:44 +0000 Message-ID: <97d0ab6c6b3a4eb7b83c4259ee1d0d6c@BY2PR03MB128.namprd03.prod.outlook.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.62.209.16] x-forefront-prvs: 0035B15214 x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(377454003)(199002)(189002)(51704005)(31966008)(46102001)(47446002)(76796001)(83072001)(76786001)(56816003)(77096001)(76576001)(561944002)(33646001)(51856001)(74316001)(74502001)(74662001)(1941001)(74366001)(53806001)(80022001)(87266001)(76482001)(2656002)(224313003)(224303002)(87936001)(74706001)(81342001)(81542001)(79102001)(85306002)(50986001)(81816001)(77982001)(19580395003)(4396001)(49866001)(83322001)(47976001)(54356001)(19580405001)(63696002)(80976001)(47736001)(66066001)(74876001)(81686001)(56776001)(54316002)(59766001)(69226001)(15975445006)(65816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB126; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:125.62.209.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:19:56 -0000 SGkgTGluZGEgLSBJIGFncmVlIHRoYXQgaXQgaXMgbm90IGEgbXVzdCBoYXZlLCBidXQgZGVmaW5p dGVseSBhIFNIT1VMRC4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHBvaW50IGFib3V0 IG1vc3QgVFMgY29ubmVjdGVkIHRvIHNpbmdsZSBOVkUsIHdvdWxkbid0IHRoZSBjYXNlIGJlIHdo ZXJlIG1vc3QgVFNlcyB3b3VsZCBiZSBjb25uZWN0ZWQgdG8gZGlmZmVyZW50IE5WRSBhcyBpbiBk aWZmZXJlbnQgaHlwZXJ2aXNvcnMgdGhhdCBhcmUgZG9pbmcgZW5jYXAvZGVjYXA/DQoNCkp1c3Qg dG8gZWxhYm9yYXRlIHRoZSBleGFtcGxlIEkgZ2F2ZSBlYXJsaWVyLCBpbiB0aGUgbGl2ZSBtaWdy YXRpb24gKG9yIHZNb3Rpb24pIG9yIGNsdXN0ZXIgZmFpbG92ZXIgc2NlbmFyaW8sIHRoZSBDQSBh ZGRyZXNzIHRvIFBBIGFkZHJlc3MgbWFwcGluZyBjaGFuZ2VzIGFuZCBhbiBOVkEgbWF5IG5vdCBi ZSBpbnZvbHZlZCBpbiB0aGUgZGVjaXNpb24gb2YgdGhhdCBtYXBwaW5nIGNoYW5nZS4gVGhlIGNs dXN0ZXIgZmFpbG92ZXIgY2FuIGhhcHBlbiBhdXRvbWF0aWNhbGx5IHdpdGhvdXQgTlZBIGludGVy dmVudGlvbi4gSW4gdGhpcyBjYXNlLCBpZiB0aGVyZSBpcyBleGlzdGluZyBjb21tdW5pY2F0aW9u IGdvaW5nIG9uIGJldHdlZW4gdHdvIFZNcywgdG8ga2VlcCB0aGUgcHJvbWlzZSBvZiBjb250aW51 b3VzIGF2YWlsYWJpbGl0eSwgdGhlIHBhY2tldCBmbG93IG11c3QgcmVjb3ZlciB3aXRoLWluIE4g c2Vjb25kcy4gSWYgTlZBIGlzIGRvd24gZHVyaW5nIHRoaXMgdGltZSwgd2Ugd291bGQgbmVlZCBh biBpbnRlci1OVkUgY29udHJvbCBjaGFubmVsIHRvIGtlZXAgcGFja2V0IGZsb3dpbmcuIA0KDQpJ IHN1Z2dlc3QgZmV3IGNoYW5nZXMgdG8gdGhlIHRleHQgeW91IHN1Z2dlc3QsIGJlbG93Lg0KDQo0 LjQgSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgSW50ZXItTlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9j b2w/IChTdWdnZXN0ZWQgbmV3IHN1Yi1zZWN0aW9uKSBUaGVyZSBjb3VsZCBiZSB2YXJpb3VzIHJl YXNvbnMsIGxpbmsgZmFpbHVyZSwgbm9kZSBmYWlsdXJlLCBvciBvdGhlcnMsIGNhdXNpbmcgZWdy ZXNzIE5WRXMgbm90IHJlYWNoYWJsZS4gV2l0aG91dCBhbnkgTlZFPC0+TlZFIGNvbnRyb2wgcGxh bmUgcHJvdG9jb2wsIHRoZSBpbmdyZXNzIE5WRSBpcyBub3QgYXdhcmUgb2YgdGhlIHJlYWNoYWJp bGl0eSBvZiBlZ3Jlc3MgTlZFIGNhdXNpbmcgZW5jYXBzdWxhdGVkIHBhY2tldHMgdG8gZHJvcHBl ZCBzb21ld2hlcmUgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuIA0KPj5bUEddIC0gQW4gTlZFPC0+ TlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgY2FuIHByb3ZpZGUgZmFzdGVyIHJlY292ZXJ5IGZy b20gc3VjaCBmYWlsdXJlcy4gDQoNCj4+W1BHXSAtIEkgdGhpbmsgd2UgY2FuIHN0cmlrZXRocm91 Z2ggdGhpcyBhcyB0aGUgdGV4dCBhYm92ZSBzZWVtcyBzdWZmaWNpZW50IHRvIGRlc2NyaWJlIHRo ZSBwcm9ibGVtIGFuZCB2YWx1ZSBvZiBOVkU8LT5jb250cm9sIHBsYW5lLiANCklmIG1vc3QgVFNl cyBhcmUgb25seSBhdHRhY2hlZCB0byBhIHNpbmdsZSBOVkUgYW5kIHRyYWZmaWMgdG8gTlZFcyBh cmUgbm90IGFnZ3JlZ2F0ZWQgZmxvd3MsIHRoZW4gdGhlIE5WRS1OVkUgY29udHJvbCBwbGFuZSBw cm90b2NvbCBkb2VzbuKAmXQgcHJvdmlkZSBtdWNoIGJlbmVmaXRzLiAgIFVuZGVyIHRoaXMgZW52 aXJvbm1lbnQsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaGF2aW5nIOKAnE5WRS1OVkUgY29udHJv bCBwcm90b2NvbCIgaXMgd2hldGhlciB0aGUgcGFja2V0cyBiZWluZyBkcm9wcGVkIGF0IHRoZSBJ bmdyZXNzIE5WRSBvciBzb21ld2hlcmUgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsgd2hlbiBlZ3Jl c3MgTlZFIGlzIG5vdCByZWFjaGFibGUuICANCkluIGRhdGEgY2VudGVyIGVudmlyb25tZW50IHdo ZXJlIG1vc3QgY29tbXVuaWNhdGlvbnMgYXJlIGFtb25nIGFwcGxpY2F0aW9ucywgbW9zdCBsaWtl bHkgYSBzb3VyY2Ugd2lsbCBub3Qgc2VuZCBtb3JlIHBhY2tldHMgd2l0aG91dCBhY2tub3dsZWRn bWVudCBmcm9tIHRoZSBkZXN0aW5hdGlvbi4gVGhlbiB0aGUgaW1wYWN0IG9mIHdoZXJlIHRoZSBw YWNrZXQgaXMgZHJvcHBlZCBpcyBub3QgdGhhdCBiaWcuIA0KSG93ZXZlciwgaW4gYW4gZW52aXJv bm1lbnQgd2hlcmUgVFNlcyBhcmUgY29ubmVjdGVkIHRvIG11bHRpcGxlIE5WRXMsIHRoZW4gaXQg bWlnaHQgYmUgd29ydGh3aGlsZSB0byBjb25zaWRlciB0aGUgSW50ZXItTlZFIGNvbnRyb2wgcGxh bmUgcHJvdG9jb2wsIHNvIHRoYXQgaW5ncmVzcyBOVkUgY2FuIGNob29zZSBkaWZmZXJlbnQgZWdy ZXNzIE5WRSBmb3IgYSBnaXZlbiB0YXJnZXQuDQogDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTGluZGEgRHVuYmFyDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxOSwgMjAxMyA5OjM5IFBN DQpUbzogUGFua2FqIEdhcmc7IEtlbiBHcmF5OyBMQVNTRVJSRSwgTUFSQyAoTUFSQyk7IFRob21h cyBOYXJ0ZW47IFl2ZXMgSGVydG9naHMgKHloZXJ0b2doKQ0KQ2M6IG52bzNAaWV0Zi5vcmc7IEx1 Y3kgeW9uZw0KU3ViamVjdDogUmU6IFtudm8zXSBObyBuZWVkIGZvciBOVkUtTlZFIGNvbnRyb2wg cGxhbmUgW3dhcyBSZTogUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJh ZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCg0KUGFua2FqLCANCg0KT2YgY291cnNlLCBOVkUt TlZFIHByb3RvY29sIGNhbiBhZGQgYmVuZWZpdHMsIGJ1dCBpdCBhbHNvIGFkZHMgY29zdC4gQSBn b29kIGRlc2lnbiBpcyBub3QgYWJvdXQgaWYgdGhlcmUgaXMgbm90aGluZyB0byBhZGQsIGJ1dCBh Ym91dCBpZiB0aGVyZSBpcyBub3RoaW5nIHRoYXQgY2FuIGJlIHJlbW92ZWQuIA0KSWYgbW9zdCBU U2VzIGFyZSBvbmx5IGF0dGFjaGVkIHRvIGEgc2luZ2xlIE5WRSBhbmQgdHJhZmZpYyB0byBOVkVz IGFyZSBub3QgYWdncmVnYXRlZCBmbG93cywgdGhlbiB0aGUgTlZFLU5WRSBjb250cm9sIHBsYW5l IHByb3RvY29sIGRvZXNu4oCZdCBwcm92aWRlIG11Y2ggYmVuZWZpdHMuICAgVW5kZXIgdGhpcyBl bnZpcm9ubWVudCwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBoYXZpbmcg4oCcTlZFLU5WRSBjb250 cm9sIHByb3RvY29sIiBpcyB3aGV0aGVyIHRoZSBwYWNrZXRzIGJlaW5nIGRyb3BwZWQgYXQgdGhl IEluZ3Jlc3MgTlZFIG9yIHNvbWV3aGVyZSBpbiB0aGUgdW5kZXJsYXkgbmV0d29yayB3aGVuIGVn cmVzcyBOVkUgaXMgbm90IHJlYWNoYWJsZS4gIA0KSW4gZGF0YSBjZW50ZXIgZW52aXJvbm1lbnQg d2hlcmUgbW9zdCBjb21tdW5pY2F0aW9ucyBhcmUgYW1vbmcgYXBwbGljYXRpb25zLCBtb3N0IGxp a2VseSBhIHNvdXJjZSB3aWxsIG5vdCBzZW5kIG1vcmUgcGFja2V0cyB3aXRob3V0IGFja25vd2xl ZGdtZW50IGZyb20gdGhlIGRlc3RpbmF0aW9uLiBUaGVuIHRoZSBpbXBhY3Qgb2Ygd2hlcmUgdGhl IHBhY2tldCBpcyBkcm9wcGVkIGlzIG5vdCB0aGF0IGJpZy4NCiANClRoZXJlZm9yZSwgSSB0aGlu ayBpdCBpcyB3b3J0aHdoaWxlIHRvIGhhdmUgYSBzdWJzZWN0aW9uIGluIHRoZSBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQgdG8gZGVzY3JpYmUgdGhpcyB0cmFkZS1vZmYuIEl0IGlzIG5vdCBjbGVhci1j dXQgIm11c3QgaGF2ZSIgb3IgIm11c3Qgbm90IGhhdmUiLiANCkhlcmUgaXMgbXkgc3VnZ2VzdGVk IHN1YnNlY3Rpb246DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQo0LjQgSXMgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgSW50ZXItTlZFIGNvbnRyb2wg cGxhbmUgcHJvdG9jb2w/IChTdWdnZXN0ZWQgbmV3IHN1Yi1zZWN0aW9uKSBUaGVyZSBjb3VsZCBi ZSB2YXJpb3VzIHJlYXNvbnMsIGxpbmsgZmFpbHVyZSwgbm9kZSBmYWlsdXJlLCBvciBvdGhlcnMs IGNhdXNpbmcgZWdyZXNzIE5WRXMgbm90IHJlYWNoYWJsZS4gV2l0aG91dCBhbnkgTlZFPC0+TlZF IGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wsIHRoZSBpbmdyZXNzIE5WRSBpcyBub3QgYXdhcmUgb2Yg dGhlIHJlYWNoYWJpbGl0eSBvZiBlZ3Jlc3MgTlZFIGNhdXNpbmcgZW5jYXBzdWxhdGVkIHBhY2tl dHMgdG8gZHJvcHBlZCBzb21ld2hlcmUgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuIA0KIElmIG1v c3QgVFNlcyBhcmUgb25seSBhdHRhY2hlZCB0byBhIHNpbmdsZSBOVkUgYW5kIHRyYWZmaWMgdG8g TlZFcyBhcmUgbm90IGFnZ3JlZ2F0ZWQgZmxvd3MsIHRoZW4gdGhlIE5WRS1OVkUgY29udHJvbCBw bGFuZSBwcm90b2NvbCBkb2VzbuKAmXQgcHJvdmlkZSBtdWNoIGJlbmVmaXRzLiAgIFVuZGVyIHRo aXMgZW52aXJvbm1lbnQsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gaGF2aW5nIOKAnE5WRS1OVkUg Y29udHJvbCBwcm90b2NvbCIgaXMgd2hldGhlciB0aGUgcGFja2V0cyBiZWluZyBkcm9wcGVkIGF0 IHRoZSBJbmdyZXNzIE5WRSBvciBzb21ld2hlcmUgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsgd2hl biBlZ3Jlc3MgTlZFIGlzIG5vdCByZWFjaGFibGUuICANCkluIGRhdGEgY2VudGVyIGVudmlyb25t ZW50IHdoZXJlIG1vc3QgY29tbXVuaWNhdGlvbnMgYXJlIGFtb25nIGFwcGxpY2F0aW9ucywgbW9z dCBsaWtlbHkgYSBzb3VyY2Ugd2lsbCBub3Qgc2VuZCBtb3JlIHBhY2tldHMgd2l0aG91dCBhY2tu b3dsZWRnbWVudCBmcm9tIHRoZSBkZXN0aW5hdGlvbi4gVGhlbiB0aGUgaW1wYWN0IG9mIHdoZXJl IHRoZSBwYWNrZXQgaXMgZHJvcHBlZCBpcyBub3QgdGhhdCBiaWcuIA0KSG93ZXZlciwgaW4gYW4g ZW52aXJvbm1lbnQgd2hlcmUgVFNlcyBhcmUgY29ubmVjdGVkIHRvIG11bHRpcGxlIE5WRXMsIHRo ZW4gaXQgbWlnaHQgYmUgd29ydGh3aGlsZSB0byBjb25zaWRlciB0aGUgSW50ZXItTlZFIGNvbnRy b2wgcGxhbmUgcHJvdG9jb2wsIHNvIHRoYXQgaW5ncmVzcyBOVkUgY2FuIGNob29zZSBkaWZmZXJl bnQgZWdyZXNzIE5WRSBmb3IgYSBnaXZlbiB0YXJnZXQuDQoNCg0KTGluZGEgDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbnZvMyBbbWFpbHRvOm52bzMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBhbmthaiBHYXJnDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDE5LCAyMDEzIDY6MzcgQU0NCj4gVG86IEtlbiBHcmF5OyBMQVNTRVJSRSwgTUFSQyAoTUFS Qyk7IFRob21hcyBOYXJ0ZW47IFl2ZXMgSGVydG9naHMNCj4gKHloZXJ0b2doKQ0KPiBDYzogbnZv M0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+IFN1YmplY3Q6IFJlOiBbbnZvM10gTm8gbmVlZCBmb3Ig TlZFLU5WRSBjb250cm9sIHBsYW5lIFt3YXMgUmU6IFBvbGwgDQo+IGZvciBXRyBhZG9wdGlvbiBh bmQgSVBSIGNoZWNrIGZvciBkcmFmdC1uYXJ0ZW4tbnZvMy1hcmNoLTAxLnR4dA0KPiANCj4gTlZF LU5WRSBjb250cm9sIHBsYW5lIGlzIG5lZWRlZCBmb3Igb3BlcmF0aW9ucyB0aGF0IGRvbid0IG5l Y2Vzc2FyaWx5IA0KPiBuZWVkIE5WQSBpbnRlcmFjdGlvbiBvciB3aGVyZSBOVkUtTlZFIGludGVy YWN0aW9uIGNhbiBwcm92aWRlIGJldHRlciANCj4gcGVyZm9ybWFuY2UuDQo+IA0KPiBGb3IgZXhh bXBsZSwgaWYgdGhlICJtYXBwaW5ncyIgYXJlIHN0YWxlIG9uIGFuIE5WRSwgdGhlbiB0aGUgcmVj ZWl2ZXIgDQo+IE5WRSBjYW4gc2VuZCBhIGNvbnRyb2wgcGxhbmUgbWVzc2FnZSB0byB0aGUgc2Vu ZGVyIE5WRSB0byB1cGRhdGUgaXRzIA0KPiBtYXBwaW5ncy4gVGhpcyBjYW4gaGFwcGVuIGR1ZSB0 byBldmVudHMgd2hlcmUgdGhlIFZNIGxpdmUgbWlncmF0ZWQgDQo+IGZyb20gb25lIGhvc3QgdG8g YW5vdGhlciBidXQgdGhlIHNlbmRlciBOVkUgaGFzIHN0YWxlIG1hcHBpbmdzIGR1ZSB0byANCj4g ZGVsYXkgaW4gZ2V0dGluZyB0aG9zZSBtYXBwaW5ncyB1cGRhdGVkIHZpYSBOVkEuIFRoaW5rIG9m IHRoaXMgYXMgYSANCj4gaGludCBmb3IgY2FjaGUgZmx1c2ggZnJvbSB0aGUgcmVjZWl2ZXIgTlZF IHRvIHRoZSBzZW5kZXIgTlZFLg0KPiANCj4gVGhlIGNvbnRyb2wgcGxhbmUgYmV0d2VlbiBOVkUt TlZFIGNhbiBhbHNvIGJlIHVzZWQgZm9yIHByb3RvY29sIA0KPiBuZWdvdGlhdGlvbiBpbiBjYXNl IG9mIG11bHRpLXByb3RvY29sIHN1cHBvcnQgYXQgTlZFLg0KPiANCj4gUGFua2FqDQo+IA0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2VuIEdyYXkNCj4gU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMTksIDIwMTMgMTI6NTUgQU0NCj4gVG86IExBU1NFUlJFLCBNQVJDIChNQVJDKTsgVGhv bWFzIE5hcnRlbjsgWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpDQo+IENjOiBudm8zQGlldGYub3Jn OyBMdWN5IHlvbmcNCj4gU3ViamVjdDogUmU6IFtudm8zXSBObyBuZWVkIGZvciBOVkUtTlZFIGNv bnRyb2wgcGxhbmUgW3dhcyBSZTogUG9sbCANCj4gZm9yIFdHIGFkb3B0aW9uIGFuZCBJUFIgY2hl Y2sgZm9yIGRyYWZ0LW5hcnRlbi1udm8zLWFyY2gtMDEudHh0DQo+IA0KPiBJIGRvbid0IHRoaW5r IHRoZSBsb2dpY2FsIGFzc29jaWF0aW9uIG9mIHRoZSBOVkEgd2l0aCBhbiBOVkUgbmVnYXRlcyAN Cj4gVGhvbWFzIGJhc2ljIHBvaW50LiAgVGhlIGtleSB3b3JkIHlvdSB1c2UgaGVyZSBpcyAiYXBw ZWFycyIgLi4uIGluIHRoZSANCj4gZW5kLCBpdCdzIG5vdCB0aGUgTlZFIHRoYXQgb3RoZXIgTlZF cyBhcmUgZXhjaGFuZ2luZyBtYXBwaW5nIA0KPiBpbmZvcm1hdGlvbiB3aXRoLCBpdCBpcyB0aGUg TlZBIHRoYXQgaXMgY28tbG9jYXRlZC4NCj4gDQo+ICsxIGZvciBUaG9tYXMgcHJvcG9zYWwuICBZ RVMsIHlvdSBjYW4gbWFrZSBpdCBtb3JlIGV4cGxpY2l0IGluIHRoZQ0KPiBhcmNoaXRlY3R1cmUg dGhhdCAibWFwcGluZyIgaXMgd2hhdCB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgaW5zdGVhZCBvZiAN Cj4gdGhlIGdlbmVyaWMgImNvbnRyb2wiLg0KPiANCj4gV2UgY2FuIGJlYXQgTlZFLU5WRSBsaXZl bGluZXNzIHRvIGRlYXRoIHdpdGggb3RoZXIgdHJ1bmNoZW9ucy4NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBGcm9tOiBudm8zLWJvdW5jZXNAaWV0Zi5vcmcg PG52bzMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIA0KPiBMQVNTRVJSRSwgTUFSQyAo TUFSQykgPG1hcmMubGFzc2VycmVAYWxjYXRlbC1sdWNlbnQuY29tPg0KPiBTZW50OiBNb25kYXks IE5vdmVtYmVyIDE4LCAyMDEzIDY6NTggQU0NCj4gVG86IFRob21hcyBOYXJ0ZW47IFl2ZXMgSGVy dG9naHMgKHloZXJ0b2doKQ0KPiBDYzogbnZvM0BpZXRmLm9yZzsgTHVjeSB5b25nDQo+IFN1Ympl Y3Q6IFJlOiBbbnZvM10gTm8gbmVlZCBmb3IgTlZFLU5WRSBjb250cm9sIHBsYW5lIFt3YXMgUmU6 IFBvbGwgZm9yDQo+IFdHICAgICAgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJhZnQtbmFy dGVuLW52bzMtYXJjaC0wMS50eHQNCj4gDQo+IFRob21hcywNCj4gDQo+IFRoZSB3YXkgdGhhdCB5 b3UgaGF2ZSBwaHJhc2VkIHRoaXMgc2VudGVuY2UgaXMgY29uZnVzaW5nIGFuZCBuZWVkcyANCj4g Y2xhcmlmaWNhdGlvbi4NCj4gDQo+IFZhcmlvdXMgY29udHJvbCBwcm90b2NvbHMgY2FuIGJlIHVz ZWQgYmV0d2VlbiBOVkVzLCBhcyB5b3UgaW5kaWNhdGVkLg0KPiANCj4gSWYgeW91IG1lYW50IHRv IHNheSB0aGF0IHRoZXJlIGlzIG5vIG5lZWQgZm9yIE5WRXMgdG8gZXhjaGFuZ2UgYWRkcmVzcyAN Cj4gbWFwcGluZyBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZW1zZWx2ZXMsIHRoaXMgaXMgYWxzbyBk ZWJhdGFibGUuDQo+IEFuIGV4dGVybmFsIE5WQSBmb3Igc3VjaCBhIGZ1bmN0aW9uIGlzIG5vdCBh bHdheXMgcmVxdWlyZWQgaW4gbnZvMy4NCj4gV2hlbiB0aGUgTlZBIGFkZHJlc3MgbWFwcGluZyBm dW5jdGlvbiBpcyBjb2xvY2F0ZWQgd2l0aCBhbiBOVkUsIE5WRXMgDQo+IGFwcGVhciBhcyBleGNo YW5naW5nIGFkZHJlc3MgbWFwcGluZyBpbmZvcm1hdGlvbiAoanVzdCBsb29raW5nIGF0IHRoZSAN Cj4gd2lyZSkuIElHUHMgd2l0aGluIE5WRXMgYWxzbyBleGNoYW5nZSB0b3BvbG9naWNhbC9hZGRy ZXNzIG1hcHBpbmcgDQo+IGluZm9ybWF0aW9uLg0KPiANCj4gTWFyYw0KPiANCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IG52bzMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiA+IE9mIFRob21hcyBOYXJ0 ZW4NCj4gPiBTZW50OiBGcmlkYXksIE5vdmVtYmVyIDE1LCAyMDEzIDExOjE5IFBNDQo+ID4gVG86 IFl2ZXMgSGVydG9naHMgKHloZXJ0b2doKQ0KPiA+IENjOiBudm8zQGlldGYub3JnOyBMdWN5IHlv bmcNCj4gPiBTdWJqZWN0OiBbbnZvM10gTm8gbmVlZCBmb3IgTlZFLU5WRSBjb250cm9sIHBsYW5l IFt3YXMgUmU6DQo+ID4gUG9sbCBmb3IgV0cgYWRvcHRpb24gYW5kIElQUiBjaGVjayBmb3IgZHJh ZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHQNCj4gPg0KPiA+IE5WTzMgZG9lcyBub3QgbmVlZCBh biBOVkUgdG8gTlZFIGNvbnRyb2wgcHJvdG9jb2wuDQo+ID4NCj4gPiBDYWxsaW5nIHRoaXMgb3V0 IGV4cGxpY2l0bHksIGFzIGl0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgY3VycmVudCANCj4gPiBh cmNoaXRlY3R1cmUgZG9jdW1lbnQuIFRoZXJlIGlzIG5vIG5lZWQgZm9yIGFuIE5WRSB0byBOVkUg Y29udHJvbCANCj4gPiBwcm90b2NvbCwgZm9yIHRoZSBwdXJwb3NlIG9mIG1haW50YWluaW5nL3Bv cHVsYXRpbmcgdGhlIG1hcHBpbmcgDQo+ID4gdGFibGVzLiBUaGVyZSBtYXkgd2VsbCBiZSBpbnRl cmFjdGlvbnMgYmV0d2VlbiBOVkVzLCBzdWNoIGFzIHNldHRpbmcgDQo+ID4gdXAgdHVubmVscywg Y3JlYXRpbmcgc2VjdXJpdHkgYXNzb2NpYXRpb25zIGZvciBwcm90ZWN0aW5nIGRhdGEgcGxhbmUg DQo+ID4gdHJhZmZpYywgb3IgcHJvdmlkaW5nIGVycm9yIGluZGljYXRpb25zIChlLmcuLCBlcXVp dmFsZW50IG9mIElDTVAgDQo+ID4gIlRTIHVucmVhY2hhYmxlIiByZXNwb25zZXMpLg0KPiA+DQo+ ID4gSWYgZm9sayBkaXNhZ3JlZSwgbm93IHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRvIGhhdmUgdGhh dCBjb252ZXJzYXRpb24uDQo+ID4NCj4gPiAiWXZlcyBIZXJ0b2docyAoeWhlcnRvZ2gpIiA8eWhl cnRvZ2hAY2lzY28uY29tPiB3cml0ZXM6DQo+ID4NCj4gPiA+ID4+IEkgZGlzYWdyZWUgd2l0aCB0 aGUgbmVlZCBmb3IgYW4gTlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPiA+ID4NCj4gPiA+ID4g W0x1Y3ldIGRvIHlvdSB0aGluayB3ZSBuZWVkIE5WRS1OVkUgY29udHJvbCBwbGFuZT8gSQ0KPiA+ IGRvbsOi4oKs4oSidCB0aGluaw0KPiA+ID4gPiB0aGlzIGlzIHdoYXQgeW91IG1lYW4gZnJvbSB0 aGUgZm9sbG93aW5nIHN0YXRlbWVudC4NCj4gPiA+DQo+ID4gPiBObyB3ZSBkb250IG5lZWQgYW4g TlZFIHRvIE5WRSBjb250cm9sIHBsYW5lLg0KPiA+ID4NCj4gPiA+ID4+IFRoYXQgZG9lc24ndCBt ZWFuIHRoYXQgeW91IGNhbid0IGNvbG9jYXRlIGEgcG9ydGlvbiBvZiB0aGUgDQo+ID4gPiA+PiBk aXN0cmlidXRlZCBOVkEgd2l0aCBldmVyeSBOVkUsIHdoaWNoIGlzIHRoZSBtb2RlbCB0aGF0IGUu Zy4NCj4gPiA+ID4+IEJHUC9MM1ZQTiBvciBJU0lTL1RSSUxMIHVzZXMuDQo+ID4gPg0KPiA+ID4g PiBbTHVjeV0gQWdyZWVkLiBOVkEgY2FuIGNvbGxvY2F0ZSB3LyBOVkUuIChwYXJ0aWFsbHkgb3Ig ZW50aXJlKS4NCj4gPiA+DQo+ID4gPiBBbmQgYXMgYSByZXN1bHQgdGhlcmUgaXMgb25seSBhIG5l ZWQgZm9yIGEgY29udHJvbCBwbGFuZQ0KPiA+IGJldHdlZW4gdGhlDQo+ID4gPiBOVkUgZnVuY3Rp b24gYW5kIHRoZSBOVkEgZnVuY3Rpb24uDQo+ID4NCj4gPiBUaG9tYXMNCj4gPg0KPiA+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG52bzMgbWFp bGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9udm8zDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0K PiBudm8zQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bnZvMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm52 bzMgbWFpbGluZyBsaXN0DQpudm8zQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzMNCg== From florin@nuagenetworks.net Tue Nov 19 11:53:09 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD881AE1BB for ; Tue, 19 Nov 2013 11:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mge2hN_aMfh6 for ; Tue, 19 Nov 2013 11:53:07 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 16D411AE1CC for ; Tue, 19 Nov 2013 11:53:06 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id fb10so2035603wid.13 for ; Tue, 19 Nov 2013 11:53:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=+1pcfQRvaZTXIxaGDOVVws4wEaLfOmjUQtaZAKxmr2o=; b=UmEL3i+yh/KkKlf0+81lsOP+AIMR0b57EPd1MPZ6PY3I4yUtP+FMx2/7DBv/6CKfLH mrm/U3jW8n/89mVNBFHT+bP/N0U3tW7qO6BYPp6sI7AnvOSg6MPqu/genFx255QHWs1O Hdb0dcKlaFQIs6aYn4sYp1xAE7T7ALtYw/xGmRPNyk4K4rGBCkaAb73xLDN98cnLivbH ZbAEUNCTBR6B2pkW4fxFRpNct9jMfhsIYZaaIxXMqa07Ad0vjdMGDqTXYzOwyEH3wlgF 2ho32V+QZ5GRfVijhjht3pGkgmUwRei76+5B9Hf4Dt5VIOsHtfGzikXBftn0khg9RRlB U4fA== X-Gm-Message-State: ALoCoQnmvFYZZc59Pm0cMHa3JhEXi2+rMlKnsc3moP5jEFZsF11llVfC6cf/58ilBLB1d3tLQmg+ X-Received: by 10.181.11.197 with SMTP id ek5mr21993428wid.7.1384890780422; Tue, 19 Nov 2013 11:53:00 -0800 (PST) Received: from [135.227.220.163] (63-233-76-254.dia.static.qwest.net. [63.233.76.254]) by mx.google.com with ESMTPSA id gg20sm584040wic.1.2013.11.19.11.52.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 19 Nov 2013 11:53:00 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.0.121105 Date: Tue, 19 Nov 2013 11:52:48 -0800 From: Florin Balus To: "LASSERRE, MARC (MARC)" , Thomas Narten , "Yves Hertoghs (yhertogh)" Message-ID: Thread-Topic: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Cc: "nvo3@ietf.org" , Lucy yong Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:53:09 -0000 I agree with Marc, the question is open to interpretation: are you talking about underlay or overlay control plane? For underlay there is definitely an IGP/BGP component that might be needed at least in some NVEs, especially when the NVE function is running on a Gateway (ToR/PE etc). >From the perspective of an NVE service overlay there are already multiple proposals in different WGs (IP VPN, L2VPN, LISP etc) designed to provide control plane for VXLAN and NVGRE-based L2/L3 services: I.e. BGP EVPN and BGP VPN are specifically designed to provide NVE2NVE distribution for certain types of NVEs. Proposals are also covering NVA2NVE or even NVA2NVA distribution. So the question is pointless IMHO, there is already a lot of traction behind building overlay/underlay control plane for NVO3 based encapsulations and there is solution work in progress elsewhere. Unless you are asking whether there is a need to do some control plane work in NVO3? If this is the question then IMHO it is going in the right direction. Although I would formulate it more generic: is NVO3 is the right place to do any solution analysis or development at this stage? On 11/18/13, 3:58 AM, "LASSERRE, MARC (MARC)" wrote: >Thomas, > >The way that you have phrased this sentence is confusing and needs >clarification. > >Various control protocols can be used between NVEs, as you indicated. > >If you meant to say that there is no need for NVEs to exchange address >mapping information between themselves, this is also debatable. >An external NVA for such a function is not always required in nvo3. When >the NVA address mapping function is colocated with an NVE, NVEs appear as >exchanging address mapping information (just looking at the wire). IGPs >within NVEs also exchange topological/address mapping information. > >Marc > >> -----Original Message----- >> From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On >> Behalf Of Thomas Narten >> Sent: Friday, November 15, 2013 11:19 PM >> To: Yves Hertoghs (yhertogh) >> Cc: nvo3@ietf.org; Lucy yong >> Subject: [nvo3] No need for NVE-NVE control plane [was Re: >> Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt >>=20 >> NVO3 does not need an NVE to NVE control protocol. >>=20 >> Calling this out explicitly, as it is consistent with the >> current architecture document. There is no need for an NVE to >> NVE control protocol, for the purpose of >> maintaining/populating the mapping tables. There may well be >> interactions between NVEs, such as setting up tunnels, >> creating security associations for protecting data plane >> traffic, or providing error indications (e.g., equivalent of >> ICMP "TS unreachable" responses). >>=20 >> If folk disagree, now would be a good time to have that conversation. >>=20 >> "Yves Hertoghs (yhertogh)" writes: >> =20 >> > >> I disagree with the need for an NVE to NVE control plane. >> >=20 >> > > [Lucy] do you think we need NVE-NVE control plane? I >> don=C3=A2=E2=82=AC=E2=84=A2t think =20 >> > > this is what you mean from the following statement. >> >=20 >> > No we dont need an NVE to NVE control plane. >> >=20 >> > >> That doesn't mean that you can't colocate a portion of the >> > >> distributed NVA with every NVE, which is the model that e.g. >> > >> BGP/L3VPN or ISIS/TRILL uses. >> >=20 >> > > [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >> >=20 >> > And as a result there is only a need for a control plane >> between the=20 >> > NVE function and the NVA function. >>=20 >> Thomas >>=20 >>=20 >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Tue Nov 19 16:21:12 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B275D1AE23E for ; Tue, 19 Nov 2013 16:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtBE2dzOZXxk for ; Tue, 19 Nov 2013 16:21:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AB1E81AE22E for ; Tue, 19 Nov 2013 16:21:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYC14116; Wed, 20 Nov 2013 00:21:00 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 00:20:51 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 00:20:58 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 16:20:47 -0800 From: Lucy yong To: Thomas Narten Thread-Topic: [nvo3] Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YZb/F/PxUTviEiLdxEQDV3PCg== Date: Wed, 20 Nov 2013 00:20:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.177] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452FF2EAdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 00:21:13 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452FF2EAdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, How about the following text: A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment. An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE), traffic is given L3 semantics. Otherwise, the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Comment: should we use a tenant system (TS) or a tenant in the text to make= consistency? Regards, Lucy ---------- Forwarded message ---------- From: Thomas Narten > Date: Mon, Nov 18, 2013 at 3:25 PM Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service To: nvo3@ietf.org There has been some discussion on the list about whether or not to have a combined L2/L3 service. Here is proposed text for the architecture document: A virtual network can also provide a combined L2 and L3 service to tenants. In such cases, a tenant sends and receives both L2 and L3 packets. An NVE recieving packets from a TS determines the type of service to be applied to the packet on a per-packet basis as indicated by the packet's destination MAC address as provided by the TS. If the MAC address corresponds to that of an L3 router (as determined by the NVE), traffic is given L3 semantics. Otherwise, the packet is given L2 service semantics. A combined L2/L3 service presents no special considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. This text would go at the end of Section 3.1 "VN Service (L2 and L3)". Make sense? Additional thinking behind this (taken from mail within the DT): > FWIW, I think that there are separate issues here. One is simply > describing what we mean by a combined L2/L3 service. That is what my > text was trying to do. The thinking is if the service definition is > clear and simple, supporting it in NVO3 is not a problem. I.e., it's > not really much different to provide a combined service than if you > offer an L2 or L3 service. And the service semantics for combined > L2/L3 are easy to understand and explain. That is goodness. :-) > > Whether and how it makes sense to have distributed gateways in a > combined service is a separate matter. What I'd like to be able to do > here (if we need to say anything at all) is be able to say that if a > distributed GW makes sense for L2 service, then having an L2 > distributed GW for the L2 traffic would make sense in the combined > service case too. Ditto for L3 service. > > A key point is that having a combined service is pretty much the same > as taking the two separate L2 and L3 services and combining them into > one implementation. There is nothing really "special" about this that > would complicate the overall architecture. Where we can easily get > into trouble is if we start defining a combined service as has special > cases that have to be dealt with that don't appear when you have only > L2 or only L3 service semantics. Thomas _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --_000_2691CE0099834E4A9C5044EEC662BB9D452FF2EAdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Thomas,<= /span>

How about the followin= g text:

A tenant network = may require both L2 and L3
services, i.e. the packets from a tenant= may get L2 and/or L3 treatment.

        &nbs= p; An NVE receiving packets from a TS determines the type of service t= o be applied to
the packet on a per-packet basis and as = indicated by the
destination MAC address on the packet. &= nbsp;If
the MAC address corresponds to that of a= n L3 router (as
determined by the NVE), traffic is given= L3
semantics. Otherwise, the packet is give= n L2
semantics. Thus the packet from a tenant= must contain IP header (as well

         as = Ethernet header) . A combined L2/L3 service presents no special
considerations for NVO3, other than pack= ets received from a
tenant must be classified as to what typ= e of service they
are to be given before they can be proce= ssed.

Comment: should we use a tenant system (TS) or a ten= ant in the text to make consistency?

Regards,

Lucy=

---------- Forwarded message ----------
From: Thomas Narten <narten@= us.ibm.com>
Date: Mon, Nov 18, 2013 at 3:25 PM
Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service
To: nvo3@ietf.org

There has been some discussion on the list about whether or not to
have a combined L2/L3 service. Here is proposed text for the
architecture document:

<t>
A virtual network can also provide a com= bined L2 and L3
service to tenants. In such cases, a ten= ant sends and
receives both L2 and L3 packets. An NVE = recieving packets
from a TS determines the type of service= to be applied to
the packet on a per-packet basis as indi= cated by the
packet's destination MAC address as prov= ided by the TS. If
the MAC address corresponds to that of a= n L3 router (as
determined by the NVE), traffic is given= L3
semantics. Otherwise, the packet is give= n L2 service
semantics. A combined L2/L3 service pres= ents no special
considerations for NVO3, other than pack= ets received from a
tenant must be classified as to what typ= e of service they
are to be given before they can be proce= ssed.
</t>

This text would go at the end of Section 3.1 "VN Service (L2 and L3)&q= uot;.

Make sense?

Additional thinking behind this (taken from mail within the DT):

> FWIW, I think that there are separate issues here. One is simply
> describing what we mean by a combined L2/L3 service. That is what my > text was trying to do. The thinking is if the service definition is > clear and simple, supporting it in NVO3 is not a problem. I.e., it's > not really much different to provide a combined service than if you > offer an L2 or L3 service. And the service semantics for combined
> L2/L3 are easy to understand and explain. That is goodness. :-)<= br> >
> Whether and how it makes sense to have distributed gateways in a
> combined service is a separate matter. What I'd like to be able to do<= br> > here (if we need to say anything at all) is be able to say that if a > distributed GW makes sense for L2 service, then having an L2
> distributed GW for the L2 traffic would make sense in the combined
> service case too. Ditto for L3 service.
>
> A key point is that having a combined service is pretty much the same<= br> > as taking the two separate L2 and L3 services and combining them into<= br> > one implementation. There is nothing really "special" about = this that
> would complicate the overall architecture. Where we can easily get
> into trouble is if we start defining a combined service as has special=
> cases that have to be dealt with that don't appear when you have only<= br> > L2 or only L3 service semantics.

Thomas

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--_000_2691CE0099834E4A9C5044EEC662BB9D452FF2EAdfweml509mbxchi_-- From nordmark@acm.org Tue Nov 19 16:56:09 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854731AE256 for ; Tue, 19 Nov 2013 16:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWtZv-hsB4CE for ; Tue, 19 Nov 2013 16:56:07 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 539F51AE260 for ; Tue, 19 Nov 2013 16:56:07 -0800 (PST) Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAK0trlc012320 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 19 Nov 2013 16:55:54 -0800 Message-ID: <528C0898.4000108@acm.org> Date: Tue, 19 Nov 2013 16:55:52 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Lucy yong , Thomas Narten References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;5iqagX5R4xG+II9G53gOpw== M;GsH3gX5R4xG+II9G53gOpw== Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 00:56:09 -0000 Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the router receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast depends on whether the input port is L2 or L3, and in some cases that will result in both bridging the packet out other L2 ports, and forwarding the packet out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3 > treatment. > > An NVE receiving packets from a TS determines the type of > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP > header (as well > > as Ethernet header) . A combined L2/L3 service presents no > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to > have a combined L2/L3 service. Here is proposed text for the > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply > > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's > > not really much different to provide a combined service than if you > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > > > > Whether and how it makes sense to have distributed gateways in a > > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined > > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the same > > as taking the two separate L2 and L3 services and combining them into > > one implementation. There is nothing really "special" about this that > > would complicate the overall architecture. Where we can easily get > > into trouble is if we start defining a combined service as has special > > cases that have to be dealt with that don't appear when you have only > > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > From lucy.yong@huawei.com Tue Nov 19 19:41:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2841A1AE1B6 for ; Tue, 19 Nov 2013 19:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYPTjQ3kP4xS for ; Tue, 19 Nov 2013 19:41:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A1DA41AE17C for ; Tue, 19 Nov 2013 19:41:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYC25816; Wed, 20 Nov 2013 03:41:45 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 03:41:34 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 03:41:43 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 19:41:33 -0800 From: Lucy yong To: Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otcSsw Date: Wed, 20 Nov 2013 03:41:33 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> In-Reply-To: <528C0898.4000108@acm.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 03:41:56 -0000 Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org]=20 Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or=20 > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my =20 > > text was trying to do. The thinking is if the service definition is =20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's =20 > > not really much different to provide a combined service than if you =20 > > offer an L2 or L3 service. And the service semantics for combined >=20 > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do =20 > > here (if we need to say anything at all) is be able to say that if a =20 > > distributed GW makes sense for L2 service, then having an L2 >=20 > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special"=20 > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > From kvivek@broadcom.com Tue Nov 19 21:07:46 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137E1AE301 for ; Tue, 19 Nov 2013 21:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK8m0jogCJkg for ; Tue, 19 Nov 2013 21:07:43 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id CE13B1AE2FF for ; Tue, 19 Nov 2013 21:07:43 -0800 (PST) Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 19 Nov 2013 21:06:36 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 19 Nov 2013 21:07:30 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 19 Nov 2013 21:07:30 -0800 From: "Vivek Kumar" To: "Lucy yong" , "Erik Nordmark" , "Thomas Narten" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5aJ8FzUGgp4qbUmCVEbHSql+F5otjY2A Date: Wed, 20 Nov 2013 05:07:29 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7E929CD61SC9506389-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 05:07:46 -0000 Hi Lucy , One comment regarding your statement . It should also be specified how to = detect if Tenant Frame has to be L2 serviced or L3 serviced when decapsulat= ing NVO3 overlay header . Regards, Vivek -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 9:12 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org]=20 Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or=20 > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my =20 > > text was trying to do. The thinking is if the service definition is =20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's =20 > > not really much different to provide a combined service than if you =20 > > offer an L2 or L3 service. And the service semantics for combined >=20 > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do =20 > > here (if we need to say anything at all) is be able to say that if a =20 > > distributed GW makes sense for L2 service, then having an L2 >=20 > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special"=20 > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From kreeger@cisco.com Tue Nov 19 21:15:33 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B491AE30B for ; Tue, 19 Nov 2013 21:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2xiESRG5ZDd for ; Tue, 19 Nov 2013 21:15:31 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id D65CF1AE309 for ; Tue, 19 Nov 2013 21:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8290; q=dns/txt; s=iport; t=1384924524; x=1386134124; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tRiK1vfUC5dZ0zWnKCwtc9IyoB3ipfYkHNpzKCP3ZiM=; b=A1S9RwJKs8En3ly+HxYqz8Sdj3VNLSH7YjxAjaTnZE7aqo1WB6EBa+e2 AelIo2Sg4rEoPD6osPQJBEwn+UihsP2RJIUIhFHNpkULE5nuHikktkVci aLCqTDFXJ3WuH34vpxffxpuqLK0/2Uj5m+wjWnikt39t7OqsNrmbuloJV Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAZEjFKtJXHA/2dsb2JhbABZgwc4U757gRUWdIIlAQEBBAEBATc0CwwGAQgOAwECAQEBAR4JLgsUAwYIAgQBDQWIAQ3AFhMEjhwBAYE5BwaELAOYEopXhzaDKIFxOQ X-IronPort-AV: E=Sophos;i="4.93,734,1378857600"; d="scan'208";a="815604" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-6.cisco.com with ESMTP; 20 Nov 2013 05:15:22 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAK5FNR2017776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 05:15:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 23:15:23 -0600 From: "Larry Kreeger (kreeger)" To: Vivek Kumar , Lucy yong , "Erik Nordmark" , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a51Nxf6uMHAT0CnA/uMI4zioJotYVwA Date: Wed, 20 Nov 2013 05:15:22 +0000 Message-ID: In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <54E58B588BAFCE4ABAED4CD76A537EE3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 05:15:34 -0000 Hi Vivek, Can you explain what you mean? We are discussing the service provided to the TS. How would it look different to the TS for "L2 serviced or L3 serviced when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how >to detect if Tenant Frame has to be L2 serviced or L3 serviced when >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the >broadcast/multicast packet should be sent to another VN is depend on >inter VN policy. It is possible. When the broadcast/multicast packet >deliver to the L3 router too. If the policy allows the >broadcast/multicast to broadcast to another VN, L3 router will forward >the packet to another VN with the same DMAC. If the policy does not >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3 >treatment.=20 > An NVE receiving packets from a TS determines the type of >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the >inter-VN policy,=20 > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP header >(as well > as Ethernet header) . A combined L2/L3 service presents no >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead the >router receives all of them and processes them based on the L3 multicast >FIB. > >(For products which implement both L2 and L3 the processing of multicast >depends on whether the input port is L2 or L3, and in some cases that >will result in both bridging the packet out other L2 ports, and >forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text to >> make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to >> have a combined L2/L3 service. Here is proposed text for the >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply > >> describing what we mean by a combined L2/L3 service. That is what my >> > text was trying to do. The thinking is if the service definition is >> > clear and simple, supporting it in NVO3 is not a problem. I.e., it's >> > not really much different to provide a combined service than if you >> > offer an L2 or L3 service. And the service semantics for combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > > >> Whether and how it makes sense to have distributed gateways in a > >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if a >> > distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined > >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the >> same > as taking the two separate L2 and L3 services and combining >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where >> we can easily get > into trouble is if we start defining a combined >> service as has special > cases that have to be dealt with that don't >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From kvivek@broadcom.com Tue Nov 19 22:00:24 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9401AE32A for ; Tue, 19 Nov 2013 22:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGHwG0TH9_Lg for ; Tue, 19 Nov 2013 22:00:21 -0800 (PST) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 765201AE326 for ; Tue, 19 Nov 2013 22:00:21 -0800 (PST) Received: from [10.9.208.53] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 19 Nov 2013 21:59:42 -0800 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 19 Nov 2013 22:00:12 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 19 Nov 2013 22:00:12 -0800 From: "Vivek Kumar" To: "Larry Kreeger (kreeger)" , "Lucy yong" , "Erik Nordmark" , "Thomas Narten" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5aJ8FzUGgp4qbUmCVEbHSql+F5otjY2AgACMUAD//394gA== Date: Wed, 20 Nov 2013 06:00:11 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7E9290444RS9590738-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:00:24 -0000 Hi Larry, Consider following diagram .=20 TS1->NVE1->L3 network ->NVE2->TS2 . Now , I can have L2/L3 services between TS attached to NVE1 and NVE2 . Lucy= comment clearly explains how NVE1 will detect whether to perform L2 or L3 = services for Tenant frame . My question is when NVE2 decapsulates the packe= t , how it will know which service to provide .=20 Let me know if I am still not clear. Regards, Vivek -----Original Message----- From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com]=20 Sent: Wednesday, November 20, 2013 10:45 AM To: Vivek Kumar; Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Vivek, Can you explain what you mean? We are discussing the service provided to the TS. How would it look different to the TS for "L2 serviced or L3 serviced when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how >to detect if Tenant Frame has to be L2 serviced or L3 serviced when >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the >broadcast/multicast packet should be sent to another VN is depend on >inter VN policy. It is possible. When the broadcast/multicast packet >deliver to the L3 router too. If the policy allows the >broadcast/multicast to broadcast to another VN, L3 router will forward >the packet to another VN with the same DMAC. If the policy does not >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3 >treatment.=20 > An NVE receiving packets from a TS determines the type of >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the >inter-VN policy,=20 > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP header >(as well > as Ethernet header) . A combined L2/L3 service presents no >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead the >router receives all of them and processes them based on the L3 multicast >FIB. > >(For products which implement both L2 and L3 the processing of multicast >depends on whether the input port is L2 or L3, and in some cases that >will result in both bridging the packet out other L2 ports, and >forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text to >> make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to >> have a combined L2/L3 service. Here is proposed text for the >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply > >> describing what we mean by a combined L2/L3 service. That is what my >> > text was trying to do. The thinking is if the service definition is >> > clear and simple, supporting it in NVO3 is not a problem. I.e., it's >> > not really much different to provide a combined service than if you >> > offer an L2 or L3 service. And the service semantics for combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > > >> Whether and how it makes sense to have distributed gateways in a > >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if a >> > distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined > >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the >> same > as taking the two separate L2 and L3 services and combining >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where >> we can easily get > into trouble is if we start defining a combined >> service as has special > cases that have to be dealt with that don't >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From david.i.allan@ericsson.com Tue Nov 19 23:40:36 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5BD1AE0EA for ; Tue, 19 Nov 2013 23:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_5Flca4xLZa for ; Tue, 19 Nov 2013 23:40:33 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 23B851AC499 for ; Tue, 19 Nov 2013 23:40:33 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-d4-528c67660d08 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 44.D2.23183.6676C825; Wed, 20 Nov 2013 08:40:22 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 20 Nov 2013 02:40:22 -0500 From: David Allan I To: Lucy yong , Erik Nordmark , "Thomas Narten" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YZb/F/PxUTviEiLdxEQDV3PCpotn0oAgAAuSoD//+wA4A== Date: Wed, 20 Nov 2013 07:40:22 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPlG5aek+QQdtsS4u7LROZLDb+WsRm caJvKotF/9SdTBZP50s6sHpcvuLt0XLkLavHkiU/mTzOXetjDmCJ4rJJSc3JLEst0rdL4Mo4 tekxY0GrU8Xu22dZGxjfG3YxcnJICJhI7NnXxghhi0lcuLeerYuRi0NI4AijRN+f/8wgCSGB 5YwSE5qKQWw2AQOJPf+/gDWICORKbF7fDWYzC3hLzHu7jh3EFhbwkPi55iUTRI2nxJTDi6Fs J4mp8z+zgNgsAqoSV372AcU5OHgFfCX+tlpA7G1lkpjw5ycrSA2nQJjEqv6ZYPMZgY77fmoN E8QucYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtrLEkif7WSDqdSQW7P7EBmFrSyxb+BqsnldA UOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25ksIkRGFPHJNh0dzDueWl5iFGa g0VJnPfLW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwVut9ibWMWHiudfNfg3yTNzV/c l5RwcjB9sC9cw7RygRh7z4ce0ezl9i7XZunbftt+zFN34tyTb1df4nA5r2J2M60h+ih75DY+ CUX2/ttakxquPnrTUJz89VbpkSvdUaWHf+58UOK3r1GFo3jH3QYn3n+B/66VBc8UUpm0ZMF+ ObUv+bXvDTcrsRRnJBpqMRcVJwIA0Tzz9HcCAAA= Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 07:40:36 -0000 I believe you are over complicating this. There are L2 multicast frames that have no L3 significance and are confined= to the L2 broadcast domain. And there are L3 multicast frames that are als= o multicast or broadcast in the L2 domain (depending on if L2 filtering pru= nes the L2 topology or not). Any IP multicast frame has L2 terminated and is processed at L3. From an L= 2 POV the NVE is a bud node. It may simply go no further or mapped to one o= r more other subnets....(which may require the equivalent of additional edg= e replication if that is how mcast Is implemented).... I see this as a well understood behavior. Pulling policy into it is conflat= ing the concept significantly....There is significant NVE/NVA interactions = required to offer L3 multicast long before considering policy that should b= e in or out of scope. My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 4:42 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org] Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is=20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's=20 > > not really much different to provide a combined service than if you=20 > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a=20 > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special" > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From Garg.Pankaj@microsoft.com Wed Nov 20 00:07:43 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C971AC4C1 for ; Wed, 20 Nov 2013 00:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL2k-z-07spw for ; Wed, 20 Nov 2013 00:07:39 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE41AE0EA for ; Wed, 20 Nov 2013 00:07:38 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 08:07:21 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.123]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 08:07:21 +0000 From: Pankaj Garg To: Vivek Kumar , "Larry Kreeger (kreeger)" , Lucy yong , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a51x/0mA215b0K5pn/ZOIA0I5otk6kAgAAMhYCAACLMkA== Date: Wed, 20 Nov 2013 08:07:20 +0000 Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:7020:1020:1d2b:6fc2:d128:cf8e] x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(2473001)(189002)(51704005)(199002)(479174003)(24454002)(377454003)(13464003)(164054003)(51444003)(76796001)(74876001)(54356001)(53806001)(76786001)(74706001)(77982001)(76576001)(56816003)(51856001)(77096001)(69226001)(59766001)(85306002)(33646001)(63696002)(76482001)(15975445006)(83072001)(47446002)(19580395003)(47976001)(81342001)(54316002)(87936001)(87266001)(50986001)(83322001)(19580405001)(80022001)(46102001)(56776001)(2656002)(74662001)(31966008)(81686001)(81542001)(65816001)(79102001)(74502001)(49866001)(4396001)(47736001)(80976001)(74316001)(81816001)(74366001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB128; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:2001:4898:7020:1020:1d2b:6fc2:d128:cf8e; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:07:43 -0000 Wouldn't the decision to do L2 or L3 service be based on the inner frame fi= elds i.e. destination MAC/IP in the inner frame? Similar to how switches/ro= uters process packets i.e. based on frame's destination MAC and destination= IP address (if present)? IMHO, Thomas's original text (pasted below) describes this quite well and c= oncisely. >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> Pankaj -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Vivek Kumar Sent: Wednesday, November 20, 2013 11:30 AM To: Larry Kreeger (kreeger); Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Larry, Consider following diagram .=20 TS1->NVE1->L3 network ->NVE2->TS2 . Now , I can have L2/L3 services between TS attached to NVE1 and NVE2 . Lucy= comment clearly explains how NVE1 will detect whether to perform L2 or L3 = services for Tenant frame . My question is when NVE2 decapsulates the packe= t , how it will know which service to provide .=20 Let me know if I am still not clear. Regards, Vivek -----Original Message----- From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com]=20 Sent: Wednesday, November 20, 2013 10:45 AM To: Vivek Kumar; Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Vivek, Can you explain what you mean? We are discussing the service provided to the TS. How would it look different to the TS for "L2 serviced or L3 serviced when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how >to detect if Tenant Frame has to be L2 serviced or L3 serviced when >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the >broadcast/multicast packet should be sent to another VN is depend on >inter VN policy. It is possible. When the broadcast/multicast packet >deliver to the L3 router too. If the policy allows the >broadcast/multicast to broadcast to another VN, L3 router will forward >the packet to another VN with the same DMAC. If the policy does not >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3 >treatment.=20 > An NVE receiving packets from a TS determines the type of >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the >inter-VN policy,=20 > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP header >(as well > as Ethernet header) . A combined L2/L3 service presents no >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead the >router receives all of them and processes them based on the L3 multicast >FIB. > >(For products which implement both L2 and L3 the processing of multicast >depends on whether the input port is L2 or L3, and in some cases that >will result in both bridging the packet out other L2 ports, and >forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text to >> make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to >> have a combined L2/L3 service. Here is proposed text for the >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply > >> describing what we mean by a combined L2/L3 service. That is what my >> > text was trying to do. The thinking is if the service definition is >> > clear and simple, supporting it in NVO3 is not a problem. I.e., it's >> > not really much different to provide a combined service than if you >> > offer an L2 or L3 service. And the service semantics for combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > > >> Whether and how it makes sense to have distributed gateways in a > >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if a >> > distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined > >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the >> same > as taking the two separate L2 and L3 services and combining >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where >> we can easily get > into trouble is if we start defining a combined >> service as has special > cases that have to be dealt with that don't >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From Balaji.P@freescale.com Wed Nov 20 02:01:25 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF31AD8F2 for ; Wed, 20 Nov 2013 02:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhVEyLkpqIzb for ; Wed, 20 Nov 2013 02:01:22 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id A189C1AE3BB for ; Wed, 20 Nov 2013 02:01:22 -0800 (PST) Received: from mail193-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE018.bigfish.com (10.243.66.81) with Microsoft SMTP Server id 14.1.225.22; Wed, 20 Nov 2013 10:01:16 +0000 Received: from mail193-co1 (localhost [127.0.0.1]) by mail193-co1-R.bigfish.com (Postfix) with ESMTP id 3124BCC0644; Wed, 20 Nov 2013 10:01:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zf7Izbb2dI98dI9371I542I1432I1418I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0hbe9i1155h) Received: from mail193-co1 (localhost.localdomain [127.0.0.1]) by mail193-co1 (MessageSwitch) id 1384941674143984_32633; Wed, 20 Nov 2013 10:01:14 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.229]) by mail193-co1.bigfish.com (Postfix) with ESMTP id 157D340086; Wed, 20 Nov 2013 10:01:14 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 20 Nov 2013 10:01:11 +0000 Received: from 039-SN2MPN1-023.039d.mgd.msft.net ([169.254.3.171]) by 039-SN1MMR1-004.039d.mgd.msft.net ([::1]) with mapi id 14.03.0158.002; Wed, 20 Nov 2013 10:01:08 +0000 From: Balaji P To: Lucy yong , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YZb/F/PxUTviEiLdxEQDV3PCpotS3gAgAAuSoCAAGoHoA== Date: Wed, 20 Nov 2013 10:01:07 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.85.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 10:01:25 -0000 Lucy, As you know L2 and L3 Services for Tenant networks might be based on the Te= nant Network Topology. Where TS can be configured for multiple L2 Services = and L3 Services. IMHO treating L2 and L3 as separate services might be bett= er options w.r.t NVE. So that based on NVE configuration for L2 and L3 Serv= ices will be applied to the traffic. Regards, Balaji.P > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, November 20, 2013 9:12 AM > To: Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Erik, >=20 > Good point. L2 service provides a broadcast domain. Whether the > broadcast/multicast packet should be sent to another VN is depend on > inter VN policy. It is possible. When the broadcast/multicast packet > deliver to the L3 router too. If the policy allows the > broadcast/multicast to broadcast to another VN, L3 router will forward > the packet to another VN with the same DMAC. If the policy does not > allow, L3 router will drop the packet. >=20 > You are right, if dMAC is broadcast/multicast address, it should send to > L3 router for the further process. I change the text to following. >=20 > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3 > treatment. > An NVE receiving packets from a TS determines the type of > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a > broadcast/multicast packet, > it should be processed by the L3 router. Depending on the > inter-VN policy, > the broadcast/multicast may be allowed or prohibited. > Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP header > (as well > as Ethernet header) . A combined L2/L3 service presents no > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. >=20 >=20 > Thanks, > Lucy >=20 >=20 > -----Original Message----- > From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Tuesday, November 19, 2013 6:56 PM > To: Lucy yong; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Lucy, >=20 > What would the rules be for multicast packets? > Such packets are not addressed to a router's MAC address but instead the > router receives all of them and processes them based on the L3 multicast > FIB. >=20 > (For products which implement both L2 and L3 the processing of multicast > depends on whether the input port is L2 or L3, and in some cases that > will result in both bridging the packet out other L2 ports, and > forwarding the packet out other L3 (virtual) ports.) >=20 > Thus AFAICT the multicast rules can't depend on the destination MAC > address to determine whether L2 or L3 service should be applied. >=20 > Erik >=20 > On 11/19/13 4:20 PM, Lucy yong wrote: > > Hi Thomas, > > > > How about the following text: > > > > A tenant network may require both L2 and L3 > > services, i.e. the packets from a tenant may get L2 and/or > > L3 treatment. > > > > An NVE receiving packets from a TS determines the type of > > service to be applied to > > the packet on a per-packet basis and as indicated by the > > destination MAC address on the packet. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE), traffic is given L3 > > semantics. Otherwise, the packet is given L2 > > semantics. Thus the packet from a tenant must contain IP > > header (as well > > > > as Ethernet header) . A combined L2/L3 service presents no > > special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > Comment: should we use a tenant system (TS) or a tenant in the text to > > make consistency? > > > > Regards, > > > > Lucy > > > > ---------- Forwarded message ---------- > > From: *Thomas Narten* > > > Date: Mon, Nov 18, 2013 at 3:25 PM > > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > > To: nvo3@ietf.org > > > > > > There has been some discussion on the list about whether or not to > > have a combined L2/L3 service. Here is proposed text for the > > architecture document: > > > > > > A virtual network can also provide a combined L2 and L3 > > service to tenants. In such cases, a tenant sends and > > receives both L2 and L3 packets. An NVE recieving packets > > from a TS determines the type of service to be applied to > > the packet on a per-packet basis as indicated by the > > packet's destination MAC address as provided by the TS. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE), traffic is given L3 > > semantics. Otherwise, the packet is given L2 service > > semantics. A combined L2/L3 service presents no special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > > > Make sense? > > > > Additional thinking behind this (taken from mail within the DT): > > > > > FWIW, I think that there are separate issues here. One is simply > > > describing what we mean by a combined L2/L3 service. That is what my > > > text was trying to do. The thinking is if the service definition is > > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's > > > not really much different to provide a combined service than if you > > > offer an L2 or L3 service. And the service semantics for combined > > > L2/L3 are easy to understand and explain. That is goodness. :-) > > > > Whether and how it makes sense to have distributed gateways in a > > > combined service is a separate matter. What I'd like to be able to do > > > here (if we need to say anything at all) is be able to say that if a > > > distributed GW makes sense for L2 service, then having an L2 > > > distributed GW for the L2 traffic would make sense in the combined > > > service case too. Ditto for L3 service. > > > > > > A key point is that having a combined service is pretty much the > > same > as taking the two separate L2 and L3 services and combining > > them into > one implementation. There is nothing really "special" > > about this that > would complicate the overall architecture. Where > > we can easily get > into trouble is if we start defining a combined > > service as has special > cases that have to be dealt with that don't > > appear when you have only > L2 or only L3 service semantics. > > > > Thomas > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Wed Nov 20 03:49:07 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181CE1ADDBD for ; Wed, 20 Nov 2013 03:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jF9qtLuUeL_6 for ; Wed, 20 Nov 2013 03:49:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F14741AD73F for ; Wed, 20 Nov 2013 03:49:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD14843; Wed, 20 Nov 2013 11:48:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 11:48:45 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 11:48:55 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 03:48:43 -0800 From: Lucy yong To: Balaji P , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otcSswgAD3QQD//4/84A== Date: Wed, 20 Nov 2013 11:48:42 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF384@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 11:49:07 -0000 Hi Balaji, Please see on line. -----Original Message----- From: Balaji P [mailto:Balaji.P@freescale.com]=20 Sent: Wednesday, November 20, 2013 3:56 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, As you know L2 and L3 Services for Tenant networks might be based on the Te= nant Network Topology.=20 [Lucy] agreed. Where TS can be configured for multiple L2 Services and L3 Services. [Lucy] Do you mean the TS as network compliances w/ multiple VAPs and indiv= idual VAPs are associated to a L2 VNI or L3 VNI? If yes, agree too. IMHO treating L2 and L3 as separate services might be better options w.r.t = NVE. So that based on NVE configuration for L2 and L3 Services will be appl= ied to the traffic. [Lucy] The framework has L2 and L3 NVE service type, which apply to many ca= ses. You can use them to construct various tenant network topologies. But w= e also have the case that an NVE may serve the distributed gateway function= . In this case, the VAP may be associated to an L2 VNI on the NVE, the pack= et from a TS via the VAP may get L2 or L3 treatment on the NVE. IMO: it is = necessary to differentiate this NVE case from other the two NVE services. = =20 Thanks, Lucy Regards, Balaji.P > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, November 20, 2013 9:12 AM > To: Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Erik, >=20 > Good point. L2 service provides a broadcast domain. Whether the=20 > broadcast/multicast packet should be sent to another VN is depend on=20 > inter VN policy. It is possible. When the broadcast/multicast packet=20 > deliver to the L3 router too. If the policy allows the=20 > broadcast/multicast to broadcast to another VN, L3 router will forward=20 > the packet to another VN with the same DMAC. If the policy does not=20 > allow, L3 router will drop the packet. >=20 > You are right, if dMAC is broadcast/multicast address, it should send=20 > to > L3 router for the further process. I change the text to following. >=20 > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or=20 > L3 treatment. > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a=20 > broadcast/multicast packet, > it should be processed by the L3 router. Depending on the=20 > inter-VN policy, > the broadcast/multicast may be allowed or prohibited. > Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. >=20 >=20 > Thanks, > Lucy >=20 >=20 > -----Original Message----- > From: Erik Nordmark [mailto:nordmark@acm.org] > Sent: Tuesday, November 19, 2013 6:56 PM > To: Lucy yong; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Lucy, >=20 > What would the rules be for multicast packets? > Such packets are not addressed to a router's MAC address but instead=20 > the router receives all of them and processes them based on the L3=20 > multicast FIB. >=20 > (For products which implement both L2 and L3 the processing of=20 > multicast depends on whether the input port is L2 or L3, and in some=20 > cases that will result in both bridging the packet out other L2 ports,=20 > and forwarding the packet out other L3 (virtual) ports.) >=20 > Thus AFAICT the multicast rules can't depend on the destination MAC=20 > address to determine whether L2 or L3 service should be applied. >=20 > Erik >=20 > On 11/19/13 4:20 PM, Lucy yong wrote: > > Hi Thomas, > > > > How about the following text: > > > > A tenant network may require both L2 and L3 > > services, i.e. the packets from a tenant may get L2=20 > > and/or > > L3 treatment. > > > > An NVE receiving packets from a TS determines the type of=20 > > service to be applied to > > the packet on a per-packet basis and as indicated by the > > destination MAC address on the packet. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE), traffic is given L3 > > semantics. Otherwise, the packet is given L2 > > semantics. Thus the packet from a tenant must contain IP=20 > > header (as well > > > > as Ethernet header) . A combined L2/L3 service presents=20 > > no special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > Comment: should we use a tenant system (TS) or a tenant in the text=20 > > to make consistency? > > > > Regards, > > > > Lucy > > > > ---------- Forwarded message ---------- > > From: *Thomas Narten* > > > Date: Mon, Nov 18, 2013 at 3:25 PM > > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > > To: nvo3@ietf.org > > > > > > There has been some discussion on the list about whether or not to=20 > > have a combined L2/L3 service. Here is proposed text for the=20 > > architecture document: > > > > > > A virtual network can also provide a combined L2 and L3 > > service to tenants. In such cases, a tenant sends and > > receives both L2 and L3 packets. An NVE recieving packets > > from a TS determines the type of service to be applied to > > the packet on a per-packet basis as indicated by the > > packet's destination MAC address as provided by the TS. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE), traffic is given L3 > > semantics. Otherwise, the packet is given L2 service > > semantics. A combined L2/L3 service presents no special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > > > Make sense? > > > > Additional thinking behind this (taken from mail within the DT): > > > > > FWIW, I think that there are separate issues here. One is simply =20 > > > describing what we mean by a combined L2/L3 service. That is what=20 > > my > > > text was trying to do. The thinking is if the service definition=20 > > > is clear and simple, supporting it in NVO3 is not a problem. I.e.,=20 > > > it's not really much different to provide a combined service than=20 > > > if you offer an L2 or L3 service. And the service semantics for=20 > > > combined > > > L2/L3 are easy to understand and explain. That is goodness. :-) > =20 > > > Whether and how it makes sense to have distributed gateways in a =20 > > > combined service is a separate matter. What I'd like to be able to=20 > > do > > > here (if we need to say anything at all) is be able to say that if=20 > > > a distributed GW makes sense for L2 service, then having an L2 > > > distributed GW for the L2 traffic would make sense in the combined =20 > > > service case too. Ditto for L3 service. > > > > > > A key point is that having a combined service is pretty much the=20 > > same > as taking the two separate L2 and L3 services and combining=20 > > them into > one implementation. There is nothing really "special" > > about this that > would complicate the overall architecture. Where=20 > > we can easily get > into trouble is if we start defining a combined=20 > > service as has special > cases that have to be dealt with that=20 > > don't appear when you have only > L2 or only L3 service semantics. > > > > Thomas > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Wed Nov 20 04:18:45 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CCB1ADEA3 for ; Wed, 20 Nov 2013 04:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoFHJrbek7LK for ; Wed, 20 Nov 2013 04:18:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3071AD8F1 for ; Wed, 20 Nov 2013 04:18:41 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD17629; Wed, 20 Nov 2013 12:18:33 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:18:21 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:18:31 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 04:18:21 -0800 From: Lucy yong To: David Allan I , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otcSswgADRYwD//8ErQA== Date: Wed, 20 Nov 2013 12:18:20 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF3A6@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:18:45 -0000 See inline. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Wednesday, November 20, 2013 1:40 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service I believe you are over complicating this. There are L2 multicast frames that have no L3 significance and are confined= to the L2 broadcast domain. And there are L3 multicast frames that are als= o multicast or broadcast in the L2 domain (depending on if L2 filtering pru= nes the L2 topology or not). Any IP multicast frame has L2 terminated and is processed at L3. From an L= 2 POV the NVE is a bud node. It may simply go no further or mapped to one o= r more other subnets....(which may require the equivalent of additional edg= e replication if that is how mcast Is implemented).... I see this as a well understood behavior. Pulling policy into it is conflat= ing the concept significantly....There is significant NVE/NVA interactions = required to offer L3 multicast long before considering policy that should b= e in or out of scope. [Lucy] Yes, handling multicast traffic across VNs is more complex network f= unction regardless using distributed gateway function or a gateway. IMO, NV= O3 has to able to handle the networking policy. The policy can be simple or= very complex. Excluding the policy completely in NVO3, IMO, is it a virtua= lized network?=20 Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 4:42 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org] Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is=20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's=20 > > not really much different to provide a combined service than if you=20 > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a=20 > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special" > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From david.i.allan@ericsson.com Wed Nov 20 04:26:11 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAF31ADEC0 for ; Wed, 20 Nov 2013 04:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OKom4yCUU1y for ; Wed, 20 Nov 2013 04:26:08 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 093B31ADEA7 for ; Wed, 20 Nov 2013 04:26:07 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-ed-528caa566c66 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 31.26.23183.65AAC825; Wed, 20 Nov 2013 13:25:58 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 20 Nov 2013 07:25:59 -0500 From: David Allan I To: Lucy yong , Erik Nordmark , "Thomas Narten" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YZb/F/PxUTviEiLdxEQDV3PCpotn0oAgAAuSoD//+wA4IAApGMA//+skyA= Date: Wed, 20 Nov 2013 12:25:57 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452FF3A6@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF3A6@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyuXRPuG7Yqp4gg6tLLSzutkxkstj4axGb xYm+qSwW/VN3Mlk8nS/pwOpx+Yq3R8uRt6weS5b8ZPI4d62POYAlissmJTUnsyy1SN8ugStj 6fbf7AWPfSta+5+xNTBusu5i5OSQEDCRWPb/NDOELSZx4d56ti5GLg4hgSOMEqsbjzBCOMsZ JbbtOcIKUsUmYCCx5/8XRhBbRCBXYvP6bjCbWcBbYt7bdewgtrCAh8TPNS+ZIGo8JaYcXgxl +0k0L/nNBmKzCKhK3OyAsHkFfCWWz1kNtXkqs0Trtx0sIAlOgTCJk1fbwZoZgc77fmoNE8Qy cYlbT+YzQZwtILFkz3moF0QlXj7+xwphK0ssebKfBaJeR2LB7k9sELa2xLKFr5khFgtKnJz5 hGUCo9gsJGNnIWmZhaRlFpKWBYwsqxg5SotTy3LTjQw2MQLj6pgEm+4Oxj0vLQ8xSnOwKInz fnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUeH3N6nMR/JMqv/61pmfba1+4lHfP2Fj gqv18k8Ch77FXOr+YPeL97h7eu+1p5rbrPStG1/fmmWTcG/GBObuw6sSJztFVyscvidxreRp SXp/QOzr1KM9atoPr1475KSwon9RZVzoz5MSKrb1AZs2r70S6Rp60OTFD4OQ4Ovm0U7qRWci lqXMV2Ipzkg01GIuKk4EAGs5Rhx5AgAA Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:26:11 -0000 HI Lucy: If I am offering a tenant a combined L2/L3 service that includes multicast = then I am not sure what multicast specific policies I would be enforcing, = other than perhaps saving the tenant from themselves. If the VN connects to the internet, not sure I'd offer multicast as part of= the service, nor for tenant extranets .... My initial reaction was that there was a lot of other things that needed to= work to implement L3 multicast before we started considering policy....and= use cases for policy did not leap out at me.... I hope this helps Dave -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Wednesday, November 20, 2013 1:18 PM To: David Allan I; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service See inline. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, November 20, 2013 1:40 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service I believe you are over complicating this. There are L2 multicast frames that have no L3 significance and are confined= to the L2 broadcast domain. And there are L3 multicast frames that are als= o multicast or broadcast in the L2 domain (depending on if L2 filtering pru= nes the L2 topology or not). Any IP multicast frame has L2 terminated and is processed at L3. From an L= 2 POV the NVE is a bud node. It may simply go no further or mapped to one o= r more other subnets....(which may require the equivalent of additional edg= e replication if that is how mcast Is implemented).... I see this as a well understood behavior. Pulling policy into it is conflat= ing the concept significantly....There is significant NVE/NVA interactions = required to offer L3 multicast long before considering policy that should b= e in or out of scope. [Lucy] Yes, handling multicast traffic across VNs is more complex network f= unction regardless using distributed gateway function or a gateway. IMO, NV= O3 has to able to handle the networking policy. The policy can be simple or= very complex. Excluding the policy completely in NVO3, IMO, is it a virtua= lized network?=20 Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 4:42 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org] Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is=20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's=20 > > not really much different to provide a combined service than if you=20 > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a=20 > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special" > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Wed Nov 20 04:26:24 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0C1ADEA7 for ; Wed, 20 Nov 2013 04:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtmdqshpd45U for ; Wed, 20 Nov 2013 04:26:22 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CE7711ADED7 for ; Wed, 20 Nov 2013 04:26:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN21406; Wed, 20 Nov 2013 12:26:13 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:26:02 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:26:11 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 04:26:01 -0800 From: Lucy yong To: David Allan I , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otcSswgADRYwD//8g0oA== Date: Wed, 20 Nov 2013 12:26:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF3B7@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:26:24 -0000 BTW: draft-yong-nvo3-nve describes use of distributed gateway function and = a gateway. A tenant network can use one or both based on its application. N= VO3 architecture should allow these networking functions, and let the appli= cation to choose. Just like that you can choose a L2 service or L3 service. Lucy=20 -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Wednesday, November 20, 2013 1:40 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service I believe you are over complicating this. There are L2 multicast frames that have no L3 significance and are confined= to the L2 broadcast domain. And there are L3 multicast frames that are als= o multicast or broadcast in the L2 domain (depending on if L2 filtering pru= nes the L2 topology or not). Any IP multicast frame has L2 terminated and is processed at L3. From an L= 2 POV the NVE is a bud node. It may simply go no further or mapped to one o= r more other subnets....(which may require the equivalent of additional edg= e replication if that is how mcast Is implemented).... I see this as a well understood behavior. Pulling policy into it is conflat= ing the concept significantly....There is significant NVE/NVA interactions = required to offer L3 multicast long before considering policy that should b= e in or out of scope. My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 4:42 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org] Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is=20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's=20 > > not really much different to provide a combined service than if you=20 > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a=20 > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special" > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From jnc@mercury.lcs.mit.edu Wed Nov 20 04:28:54 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08A1ADEAE for ; Wed, 20 Nov 2013 04:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkrvLfhFNg2b for ; Wed, 20 Nov 2013 04:28:53 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF441ADEC8 for ; Wed, 20 Nov 2013 04:28:52 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 45DE918C147; Wed, 20 Nov 2013 07:28:46 -0500 (EST) To: nvo3@ietf.org Message-Id: <20131120122846.45DE918C147@mercury.lcs.mit.edu> Date: Wed, 20 Nov 2013 07:28:46 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: [nvo3] Top-posting X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:28:54 -0000 If people must top-post, can they at least edit out the previous 17 messages in the thread, leaving only the latest one which they are replying to? Thanks. Noel From lucy.yong@huawei.com Wed Nov 20 04:34:24 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8781ADED9 for ; Wed, 20 Nov 2013 04:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8_gcUZlTemU for ; Wed, 20 Nov 2013 04:34:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3715A1ADF56 for ; Wed, 20 Nov 2013 04:34:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD19165; Wed, 20 Nov 2013 12:34:12 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:33:56 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 12:33:55 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 04:33:43 -0800 From: Lucy yong To: David Allan I , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otcSswgADRYwD//8ErQIAAjqCA//96vMA= Date: Wed, 20 Nov 2013 12:33:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF3CF@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452FF3A6@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 12:34:24 -0000 -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of David Allan I Sent: Wednesday, November 20, 2013 6:26 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service HI Lucy: If I am offering a tenant a combined L2/L3 service that includes multicast = then I am not sure what multicast specific policies I would be enforcing, = other than perhaps saving the tenant from themselves. If the VN connects to the internet, not sure I'd offer multicast as part of= the service, nor for tenant extranets .... My initial reaction was that there was a lot of other things that needed to= work to implement L3 multicast before we started considering policy....and= use cases for policy did not leap out at me.... [Lucy] I agree and do not like to go that far now ..... =20 Lucy I hope this helps Dave -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Wednesday, November 20, 2013 1:18 PM To: David Allan I; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service See inline. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Wednesday, November 20, 2013 1:40 AM To: Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service I believe you are over complicating this. There are L2 multicast frames that have no L3 significance and are confined= to the L2 broadcast domain. And there are L3 multicast frames that are als= o multicast or broadcast in the L2 domain (depending on if L2 filtering pru= nes the L2 topology or not). Any IP multicast frame has L2 terminated and is processed at L3. From an L= 2 POV the NVE is a bud node. It may simply go no further or mapped to one o= r more other subnets....(which may require the equivalent of additional edg= e replication if that is how mcast Is implemented).... I see this as a well understood behavior. Pulling policy into it is conflat= ing the concept significantly....There is significant NVE/NVA interactions = required to offer L3 multicast long before considering policy that should b= e in or out of scope. [Lucy] Yes, handling multicast traffic across VNs is more complex network f= unction regardless using distributed gateway function or a gateway. IMO, NV= O3 has to able to handle the networking policy. The policy can be simple or= very complex. Excluding the policy completely in NVO3, IMO, is it a virtua= lized network?=20 Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Wednesday, November 20, 2013 4:42 AM To: Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Erik, Good point. L2 service provides a broadcast domain. Whether the broadcast/m= ulticast packet should be sent to another VN is depend on inter VN policy. = It is possible. When the broadcast/multicast packet deliver to the L3 route= r too. If the policy allows the broadcast/multicast to broadcast to anothe= r VN, L3 router will forward the packet to another VN with the same DMAC. I= f the policy does not allow, L3 router will drop the packet. You are right, if dMAC is broadcast/multicast address, it should send to L3= router for the further process. I change the text to following. A tenant network may require both L2 and L3 services, i.e. the packets from a tenant may get L2 and/or L3 tre= atment.=20 An NVE receiving packets from a TS determines the type of service= to be applied to the packet on a per-packet basis and as indicated by the destination MAC address on the packet. If the MAC address corresponds to that of an L3 router (as determined by the NVE) traffic is given L3 semantics with inter-VN policy. When an NVE receives a broadcast/= multicast packet,=20 it should be processed by the L3 router. Depending on the inter-V= N policy,=20 the broadcast/multicast may be allowed or prohibited. Otherwise, = the packet is given L2 semantics. Thus the packet from a tenant must contain IP header (= as well as Ethernet header) . A combined L2/L3 service presents no specia= l considerations for NVO3, other than packets received from a tenant must be classified as to what type of service they are to be given before they can be processed. Thanks, Lucy =20 -----Original Message----- From: Erik Nordmark [mailto:nordmark@acm.org] Sent: Tuesday, November 19, 2013 6:56 PM To: Lucy yong; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, What would the rules be for multicast packets? Such packets are not addressed to a router's MAC address but instead the ro= uter receives all of them and processes them based on the L3 multicast FIB. (For products which implement both L2 and L3 the processing of multicast de= pends on whether the input port is L2 or L3, and in some cases that will re= sult in both bridging the packet out other L2 ports, and forwarding the pac= ket out other L3 (virtual) ports.) Thus AFAICT the multicast rules can't depend on the destination MAC address= to determine whether L2 or L3 service should be applied. Erik On 11/19/13 4:20 PM, Lucy yong wrote: > Hi Thomas, > > How about the following text: > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > Comment: should we use a tenant system (TS) or a tenant in the text to=20 > make consistency? > > Regards, > > Lucy > > ---------- Forwarded message ---------- > From: *Thomas Narten* > > Date: Mon, Nov 18, 2013 at 3:25 PM > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > To: nvo3@ietf.org > > > There has been some discussion on the list about whether or not to=20 > have a combined L2/L3 service. Here is proposed text for the=20 > architecture document: > > > A virtual network can also provide a combined L2 and L3 > service to tenants. In such cases, a tenant sends and > receives both L2 and L3 packets. An NVE recieving packets > from a TS determines the type of service to be applied to > the packet on a per-packet basis as indicated by the > packet's destination MAC address as provided by the TS. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE), traffic is given L3 > semantics. Otherwise, the packet is given L2 service > semantics. A combined L2/L3 service presents no special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > > This text would go at the end of Section 3.1 "VN Service (L2 and L3)". > > Make sense? > > Additional thinking behind this (taken from mail within the DT): > > > FWIW, I think that there are separate issues here. One is simply >=20 > describing what we mean by a combined L2/L3 service. That is what my > > text was trying to do. The thinking is if the service definition is=20 > > clear and simple, supporting it in NVO3 is not a problem. I.e., it's=20 > > not really much different to provide a combined service than if you=20 > > offer an L2 or L3 service. And the service semantics for combined > > L2/L3 are easy to understand and explain. That is goodness. :-) > >=20 > Whether and how it makes sense to have distributed gateways in a >=20 > combined service is a separate matter. What I'd like to be able to do > > here (if we need to say anything at all) is be able to say that if a=20 > > distributed GW makes sense for L2 service, then having an L2 > > distributed GW for the L2 traffic would make sense in the combined >=20 > service case too. Ditto for L3 service. > > > > A key point is that having a combined service is pretty much the=20 > same > as taking the two separate L2 and L3 services and combining=20 > them into > one implementation. There is nothing really "special" > about this that > would complicate the overall architecture. Where=20 > we can easily get > into trouble is if we start defining a combined=20 > service as has special > cases that have to be dealt with that don't=20 > appear when you have only > L2 or only L3 service semantics. > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From narten@us.ibm.com Wed Nov 20 09:12:44 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829EE1AE4A7 for ; Wed, 20 Nov 2013 09:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYFfPcb66hDQ for ; Wed, 20 Nov 2013 09:12:42 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1051AE4A8 for ; Wed, 20 Nov 2013 09:12:42 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 12:12:35 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 12:12:34 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 88D8CC90041 for ; Wed, 20 Nov 2013 12:12:28 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKHCTIQ57934062 for ; Wed, 20 Nov 2013 17:12:29 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKHCSS1007914 for ; Wed, 20 Nov 2013 12:12:29 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKHCRBY007747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 12:12:28 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKH7MgR014153; Wed, 20 Nov 2013 12:07:22 -0500 Message-Id: <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> Comments: In-reply-to Linda Dunbar message dated "Tue, 19 Nov 2013 16:09:11 +0000." Date: Wed, 20 Nov 2013 12:07:22 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112017-7182-0000-0000-00000929E85D Cc: nvo3@ietf.org Subject: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:12:44 -0000 Linda, > If most TSes are only attached to a single NVE and traffic to NVEs > are not aggregated flows, then the NVE-NVE control plane protocol > doesn’t provide much benefits. I want to flag the first part of the sentence above because this question has been raised before. It suggests that a TS might connect to more than one NVE at a time. >From an architectural perpsective, I think we should say "no". Life is much simpler if a TS connects to a VN through exactly one NVE. More precisely, a TSI always connects to one NVE. If we allowed connections to multple NVEs simultaneously, it would raise all sorts of questions as to when to use one over the other, etc. I don't think I'm actually saying anything new with this... I've always assumed this, documents are written with this in mind, and it hasn't come up (other than in passing) on the list. A TS can still connect to multiple different VNs through different network interfaces, and hence different TSIs, but I think we should have a TSI always connect to exactly one NVE. Any other opinions? Thomas From farinacci@gmail.com Wed Nov 20 09:24:44 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED221AE470 for ; Wed, 20 Nov 2013 09:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAcbQ-F5MNUH for ; Wed, 20 Nov 2013 09:24:43 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 821C21AE0F5 for ; Wed, 20 Nov 2013 09:24:43 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id g10so5565050pdj.31 for ; Wed, 20 Nov 2013 09:24:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qJoOw9d2ewvxNOz927cbRiiKxwsaUH3iBidCW4Bjdh4=; b=tUkaB9+sqXZi2xFQ13SjrnwloKnunJeacn0ol7bnJa1Kju6NJzDxxq1exiGf3ARzxh 1wE4hMHUltBlEhM9Ki419S7LNxvI8bCK9MU5Ez32EV+ZpL1Wud9AX1M2xBL1/SlUIrR2 k5ZfkoP81Is+6YzRfgI9mMRm59sUllhyIwbfB6sdnqRtzEd3emSWecokforfl2yMlUQo Aa9zJTDGTBHcWFm3JxRWDGdM80cg6xuFy8qEy5Zzz9CQZ/0B2/6IMd8OBnyvff0sxPzK D5EjQnj8MiTfO8zGCT/Wb5/QUfO1Bb5E+T6PV6q1YWaVP6imk9n+XyBhvcpCraHF1+Kz 3tpQ== X-Received: by 10.68.58.137 with SMTP id r9mr1856288pbq.148.1384968277260; Wed, 20 Nov 2013 09:24:37 -0800 (PST) Received: from [192.168.1.101] ([207.145.253.66]) by mx.google.com with ESMTPSA id p1sm39254268pbo.12.2013.11.20.09.24.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 09:24:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> Date: Wed, 20 Nov 2013 09:24:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org, Linda Dunbar Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:24:44 -0000 > =46rom an architectural perpsective, I think we should say "no". Life = is > much simpler if a TS connects to a VN through exactly one NVE. More > precisely, a TSI always connects to one NVE. If we allowed connections > to multple NVEs simultaneously, it would raise all sorts of questions > as to when to use one over the other, etc. Thomas, just be aware that in the physical case, a server is dual = attached to multiple TORs. If each TOR is going to be an NVE, because = you want to save state in the data center core layer, then you'll have = to do multi-homing. Dino From narten@us.ibm.com Wed Nov 20 09:25:36 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11881AE4CA for ; Wed, 20 Nov 2013 09:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzxz44_ytRmk for ; Wed, 20 Nov 2013 09:25:34 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3B11AE4C6 for ; Wed, 20 Nov 2013 09:25:34 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 10:25:28 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 10:25:26 -0700 Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id C877019D8052 for ; Wed, 20 Nov 2013 10:25:20 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by b03cxnp08027.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKFNcsT21954648 for ; Wed, 20 Nov 2013 16:23:38 +0100 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKHPOEF032198 for ; Wed, 20 Nov 2013 10:25:25 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKHPNhk032128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 10:25:24 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKHPMbi016798; Wed, 20 Nov 2013 12:25:22 -0500 Message-Id: <201311201725.rAKHPMbi016798@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F645C1BA4F@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645C1BA4F@dfweml509-mbx.china.huawei.com> Comments: In-reply-to Linda Dunbar message dated "Mon, 18 Nov 2013 20:10:30 +0000." Date: Wed, 20 Nov 2013 12:25:21 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112017-7164-0000-0000-0000037E270A Cc: "Black, David" , "nvo3@ietf.org" , "LASSERRE, MARC $MARC$" , "adrian@olddog.co.uk" , Larry Kreeger , Jon Hudson Subject: Re: [nvo3] Sugggested addition-replacement to draft-narten-nvo3-arch-01 X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:25:37 -0000 Linda, Linda Dunbar writes: > I posted those comments and suggested text changes during the WG > Adoption process. Since I haven’t heard any replies from the > authors, I am re-posting my suggested addition and change of text > to draft-narten-nvo3-arch-01 plus a few more suggestions to clear > out issues being discussed on the mailing list. Apologies for not getting back sooner. These had not been forgotten, but they also require more involved response. > Issues with the current writing of Distributed Gateway (Section 5.4): > > As described in Section 5.3, a Gateway does many things. However, I > don’t think that a NVE, if taking on the responsibility of a > distributed Gateway, will do all the things that a conventional > Gateway does (or the list of items mentioned in the Section 5.3). To be clear, Section 5.4 "Distribute Gateways" was really about Inter-VN gateways. The heading could have been clearer. > First, it might be too much to ask a NVE based gateway (especially > Hypervisor based NVE) to > > · relay traffic off the virtual networks, i.e. perform gateway function to reach destinations outside the local VNs, > · serve as IPSec gateway to external (i.e. out of Virtual Networks), > · perform NAT on the source virtual addresses, or > · relay traffic to a VN that doesn’t have any hosts attached to the NVE (it is debatable if a NVE based distributed Gateway should take this responsibility) > > The meaningful functions performed by NVE, if designated as > “distributed gateway”, are more like Inter-VN relay (instead of full > blown Gateway function). Mostly agree. However, the purpose of the architecture is not to say what implementations MUST do, it's about what the architecture must allow, in order for implementations (and solutions) have the option of implementing something. So at this point, we shouldn't get too caught up in exact details of what would and would not make sense to distribute. > Second, when host “a” in VN-1 sends traffic to “b” in VN-2, the data > packet’s Ethernet header has “MAC-DA = Gateway-MAC & MAC-SA= a-MAC & > VLAN= VN-1”. Most implementations (Microsoft Window 8 and VM NSX) > allocate a “fake MAC” for all the NVE based distributed gateways to > share, so that host “a” can use the same Gateway-MAC when moved to > another NVE. This again is different from the conventional > gateways. Sure. > Third, the issue of conventional gateway (i.e. a->b traffic to be > routed at gateway even if “a” & “b” are attached to the same NVE) > is traffic “hairpinning”, instead of triangular routing. Sure. It's a special case of triangular routing. > Therefore, I suggest rewriting Section 5.4 as below: I took some of your text, but think it would be better to pull out the policy stuff into its own section. Here is proposed text:
The relaying of traffic from one VN to another deserves special consideration. Whether traffic is permitted to flow from one VN to another is a matter of policy, and would not (by default) be allowed unless explicitely enabled. In addition, NVAs are the logical place to maintain policy information about allowed inter-VN communication. Policy enforcement for inter-VN communication can be handled in (at least) two different ways. Explicit gateways could be the central point for such enforcement, with all inter-VN traffic forwarded to such gateways for processing. Alternatively, the NVA can provide such information directly to NVEs, by either providing a mapping for a target TS on another VN, or indicating that such communication is disallowed by policy. above is new text. When inter-VN gateways are centralized, traffic between TSes on different VNs can take suboptimal paths, i.e., triangular routing results in paths that always traverse the gateway. In the worst case, traffic between two TSes connected to the same NVE can be hairpinned through an external gateway. As an optimization, individual NVEs can be part of a distributed gateway that performs such relaying, reducing or completely eliminating triangular routing. In a distributed gateway, each ingress NVE can perform such relaying activity directly, so long as it has access to the policy information needed to determine whether cross-VN communication is allowed. Having individual NVEs be part of a distributed gateway allows them to tunnel traffic directly to the destination NVE without the need to take suboptimal paths. Mostly same as in existing doc, just added "hairpinning" text. The NVO3 architecture must support distributed gateways for the case of inter-VN communication. Such support requires that NVO3 control protocols include mechanisms for the maintenance and distribution of policy information about what type of cross-VN communication is allowed so that NVEs acting as distributed gateways can tunnel traffic from one VN to another as appropriate. Cleaned up and just said "must" Distributed gateways could also be used to to distribute other traditional router services to individual NVEs. The NVO3 architecture does not preclude such implementations, but does not define or require them as they are outside the scope of NVO3. Above is to basically say distributed functionality that is non-NVO3 related is out of scope for NVO3 to have an opinion on. It means implementations can do more or less what they want, NVO3 doesn't really need to take a postion. I'll respond to your other points in a subsequent message. Thomas From narten@us.ibm.com Wed Nov 20 09:31:36 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEBE1AE0E1 for ; Wed, 20 Nov 2013 09:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNJ49ChjiRvV for ; Wed, 20 Nov 2013 09:31:35 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id DF4331AE012 for ; Wed, 20 Nov 2013 09:31:34 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 10:31:28 -0700 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 10:31:26 -0700 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 59E976E803F for ; Wed, 20 Nov 2013 12:31:23 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22035.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKHVPgW9372054 for ; Wed, 20 Nov 2013 17:31:25 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKHVPqc006283 for ; Wed, 20 Nov 2013 12:31:25 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKHVN6a006137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 12:31:24 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKHVMxK017707; Wed, 20 Nov 2013 12:31:22 -0500 Message-Id: <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> To: Dino Farinacci In-reply-to: <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Wed, 20 Nov 2013 09:24:37 -0800." Date: Wed, 20 Nov 2013 12:31:22 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112017-9332-0000-0000-0000023D54D4 Cc: nvo3@ietf.org, Linda Dunbar Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:31:36 -0000 Dino, > Thomas, just be aware that in the physical case, a server is dual > attached to multiple TORs. If each TOR is going to be an NVE, > because you want to save state in the data center core layer, then > you'll have to do multi-homing. I suspect we need to dive a bit deeper into this. i.e., what does "dual attached" mean? Do you mean the NVE has two physical connections to the ToR? If so, than the question presumably is about allowing/supporting multi-homed NVEs. If the question is about the TS having two attachements to the ToR, wouldn't that be modeled (architecturally) as two distinct interfaces/ports, in which case each one can connect to its own NVE, in which case we are good? Thomas From jmh@joelhalpern.com Wed Nov 20 09:34:20 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97361AE0EB for ; Wed, 20 Nov 2013 09:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54jjiMbEHWIE for ; Wed, 20 Nov 2013 09:34:19 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7461ACC8B for ; Wed, 20 Nov 2013 09:34:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5D1E81C0884; Wed, 20 Nov 2013 09:34:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 11FB21E1F48; Wed, 20 Nov 2013 09:34:11 -0800 (PST) Message-ID: <528CF28F.50604@joelhalpern.com> Date: Wed, 20 Nov 2013 12:34:07 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Narten , Linda Dunbar References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> In-Reply-To: <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: nvo3@ietf.org Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:34:21 -0000 Most data center diagram sshow the servers (platforms hosting the TS if I understand correctly) as dual-homed to the network. This is necessary for robustness. How does that interact with asserting that TS are always connected through the VN through exactly one NVE? Yours, Joel On 11/20/13 12:07 PM, Thomas Narten wrote: > Linda, > >> If most TSes are only attached to a single NVE and traffic to NVEs >> are not aggregated flows, then the NVE-NVE control plane protocol >> doesn’t provide much benefits. > > I want to flag the first part of the sentence above because this > question has been raised before. It suggests that a TS might connect > to more than one NVE at a time. > >>From an architectural perpsective, I think we should say "no". Life is > much simpler if a TS connects to a VN through exactly one NVE. More > precisely, a TSI always connects to one NVE. If we allowed connections > to multple NVEs simultaneously, it would raise all sorts of questions > as to when to use one over the other, etc. > > I don't think I'm actually saying anything new with this... I've > always assumed this, documents are written with this in mind, and it > hasn't come up (other than in passing) on the list. > > A TS can still connect to multiple different VNs through different > network interfaces, and hence different TSIs, but I think we should > have a TSI always connect to exactly one NVE. > > Any other opinions? > > Thomas > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > From linda.dunbar@huawei.com Wed Nov 20 09:46:41 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B791AE0FA for ; Wed, 20 Nov 2013 09:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.726 X-Spam-Level: X-Spam-Status: No, score=-3.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_33=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfcEyrUkfmow for ; Wed, 20 Nov 2013 09:46:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD2F1AE403 for ; Wed, 20 Nov 2013 09:46:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN48137; Wed, 20 Nov 2013 17:46:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 17:46:21 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 17:46:30 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 09:46:24 -0800 From: Linda Dunbar To: Thomas Narten Thread-Topic: TS conects to VN through one NVE [was Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] Thread-Index: AQHO5hO/T3djuTV7YEirjhZoNIAzyZouXDXg Date: Wed, 20 Nov 2013 17:46:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C1EE5A@dfweml509-mbx.china.huawei.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> In-Reply-To: <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.176] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:46:41 -0000 VGhvbWFzLCANCg0KU2luY2UgdGhlcmUgYXJlIHF1aXRlIGEgZmV3IHBlb3BsZSBzdGF0aW5nIHRo YXQgTlZFLU5WRSBjb250cm9sIHBsYW5lIGlzIG5lZWRlZCBmb3IgTlZPMywgdGhlIGFyY2hpdGVj dHVyZSBkb2N1bWVudCBzaG91bGQgYXQgbGVhc3QgaGF2ZSBhIHN1Yi1zZWN0aW9uIGRlc2NyaWJp bmcgdGhlIHRyYWRlLW9mZiBvZiBoYXZpbmcgTlZFLU5WRSBwcm90b2NvbC4gDQoNCkV2ZW4gd2l0 aCBvbmUgVFMgYmVpbmcgY29ubmVjdGVkIHRvIG9uZSBOVkUsIHRoZXJlIGFyZSBwZW9wbGUgc2F5 aW5nIHRoYXQgb25lIE5WRSBjb3VsZCBoYXZlIHR3byBkaWZmZXJlbnQgdXBsaW5rIHBvcnRzIHRv IHVuZGVybGF5IG5ldHdvcmssIHRoZXJlZm9yZSBtaWdodCBoYXZlIHR3byBkaWZmZXJlbnQgSVAg YWRkcmVzc2VzLiBNeSBjb3VudGVyLWFyZ3VtZW50IGlzIHRoYXQgTlZFIHNob3VsZCB1c2UgaXRz IGxvb3BiYWNrIElQIGFkZHJlc3MgYW5kIGNhbiBoYXZlIGRpZmZlcmVudCBNQUMgYWRkcmVzc2Vz IGZvciBpdHMgZGlmZmVyZW50IHVwbGluayBwb3J0cyBvciB1c2UgTklDLVRlYW1pbmcgZm9yIGl0 cyBtdWx0aXBsZSBwb3J0cy4gDQoNCkkgdGhpbmsgdGhhdCBteSBzdWdnZXN0ZWQgc3Vic2VjdGlv biBpcyBuZWNlc3NhcnkgdG8gZGVzY3JpYmUgdGhlIHRyYWRlLW9mZiBhbmQgdG8gbWFrZSBXRyBm ZWVsIHRoYXQgdGhlaXIgY29tbWVudHMgYXJlIHdlbGwgYWRkcmVzc2VkLiAgDQoNCkdyYW50ZWQg dGhhdCBOVkUtTlZFIHByb3RvY29sIGRvZXMgcHJvdmlkZSBzb21lIHZhbHVlLCBsaWtlIG5vdGlm eWluZyBlYWNoIG90aGVyIHRoZSBkaXJlY3RlZCBhdHRhY2hlZCBUU2VzIHdoZW4gTlZBIGlzIG5v dCByZWFjaGFibGUsIGV0Yy4gDQpOVk8zIGFyY2hpdGVjdHVyZSBkb2Vzbid0IGhhdmUgdG8gInJl cXVpcmUgdGhpcyBwcm90b2NvbCIsIGJ1dCBkb2Vzbid0IGhhdmUgdG8gIiBleHBsaWNpdGx5IGV4 Y2x1ZGUgdGhpcyBwcm90b2NvbCAiIGVpdGhlci4gIA0KDQpBZ2FpbiBoZXJlIGlzIG15IHN1Z2dl c3RlZCBuZXcgc3Vic2VjdGlvbiAod2l0aCBtaW5vciBjaGFuZ2UgdG8gYWRkcmVzcyBQYW5rYWon cyBjb21tZW50czoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjQuNCBU aGUgdHJhZGUtb2ZmIG9mIEludGVyLU5WRSBjb250cm9sIHBsYW5lIHByb3RvY29sIChTdWdnZXN0 ZWQgbmV3IHN1Yi1zZWN0aW9uKSANCg0KVGhlcmUgY291bGQgYmUgdmFyaW91cyByZWFzb25zLCBs aW5rIGZhaWx1cmUsIG5vZGUgZmFpbHVyZSwgb3Igb3RoZXJzLCBjYXVzaW5nIGVncmVzcyBOVkVz IChvciBldmVuIE5WQSkgbm90IHJlYWNoYWJsZS4gV2l0aG91dCBhbnkgTlZFPC0+TlZFIGNvbnRy b2wgcGxhbmUgcHJvdG9jb2wsIHRoZSBpbmdyZXNzIE5WRSBpcyBub3QgYXdhcmUgb2YgdGhlIHJl YWNoYWJpbGl0eSBvZiBlZ3Jlc3MgTlZFIGNhdXNpbmcgZW5jYXBzdWxhdGVkIHBhY2tldHMgdG8g ZHJvcHBlZCBzb21ld2hlcmUgaW4gdGhlIHVuZGVybGF5IG5ldHdvcmsuIA0KDQpJZiBtb3N0IFRT ZXMgYXJlIG9ubHkgYXR0YWNoZWQgdG8gYSBzaW5nbGUgTlZFIGFuZCB0cmFmZmljIHRvIE5WRXMg YXJlIG5vdCBhZ2dyZWdhdGVkIGZsb3dzLCB0aGVuIHRoZSB2YWx1ZSBwcm92aWRlZCBieSBOVkUt TlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wgaXMgbm90IHNpZ25pZmljYW50IGNvbXBhcmVkIHRv IHRoZSBleHRyYSBjb3N0IGFkZGVkIHRvIE5WRS4gIFdoZW4gb25lIE5WRSBoYXMgbXVsdGlwbGUg dXBsaW5rIHBvcnRzIHRvIHRoZSB1bmRlcmxheSBuZXR3b3JrLCBpdCBpcyByZWNvbW1lbmRlZCB0 byB1c2UgTlZFJ3MgbG9vcGJhY2sgYWRkcmVzcyBpbnN0ZWFkIG9mIHBvcnQgYWRkcmVzc2VzIHRv IGF2b2lkIHRoZSBjb21wbGljYXRpb24gb24gaW5ncmVzcyBub2RlIGluIGRldGVybWluaW5nIHdo aWNoIGFkZHJlc3MgdG8gdXNlLiANClVuZGVyIHRoaXMgZW52aXJvbm1lbnQsIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gaGF2aW5nIKGwTlZFLU5WRSBjb250cm9sIHByb3RvY29sIiBpcyB3aGV0aGVy IHRoZSBwYWNrZXRzIGJlaW5nIGRyb3BwZWQgYXQgdGhlIEluZ3Jlc3MgTlZFIG9yIHNvbWV3aGVy ZSBpbiB0aGUgdW5kZXJsYXkgbmV0d29yayB3aGVuIGVncmVzcyBOVkUgaXMgbm90IHJlYWNoYWJs ZS4gIA0KSW4gZGF0YSBjZW50ZXIgZW52aXJvbm1lbnQgd2hlcmUgbW9zdCBjb21tdW5pY2F0aW9u cyBhcmUgYW1vbmcgYXBwbGljYXRpb25zLCBtb3N0IGxpa2VseSBhIHNvdXJjZSB3aWxsIG5vdCBz ZW5kIG1vcmUgcGFja2V0cyB3aXRob3V0IGFja25vd2xlZGdtZW50IGZyb20gdGhlIGRlc3RpbmF0 aW9uLiBUaGVuIHRoZSBpbXBhY3Qgb2Ygd2hlcmUgdGhlIHBhY2tldCBpcyBkcm9wcGVkIGlzIG5v dCB0aGF0IGJpZy4gDQpIb3dldmVyLCBpbiBhbiBlbnZpcm9ubWVudCB3aGVyZSBUU2VzIGFyZSBj b25uZWN0ZWQgdG8gbXVsdGlwbGUgTlZFcyBvciBoaWdoIGNoYW5jZSBvZiBjb25uZWN0aW9uIGZh aWx1cmUgYmV0d2VlbiBOVkUgJiBOVkEsIHRoZW4gaXQgbWlnaHQgYmUgd29ydGh3aGlsZSB0byBj b25zaWRlciB0aGUgSW50ZXItTlZFIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wsIHNvIHRoYXQgaW5n cmVzcyBOVkUgY2FuIGNob29zZSBkaWZmZXJlbnQgZWdyZXNzIE5WRSBmb3IgYSBnaXZlbiB0YXJn ZXQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpMaW5kYQ0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRob21hcyBOYXJ0ZW4gW21haWx0bzpuYXJ0ZW5A dXMuaWJtLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMCwgMjAxMyAxMTowNyBB TQ0KPiBUbzogTGluZGEgRHVuYmFyDQo+IENjOiBudm8zQGlldGYub3JnDQo+IFN1YmplY3Q6IFRT IGNvbmVjdHMgdG8gVk4gdGhyb3VnaCBvbmUgTlZFIFt3YXMgUmU6IFtudm8zXSBObyBuZWVkIGZv cg0KPiBOVkUtTlZFIGNvbnRyb2wgcGxhbmUgW3dhcyBSZTogUG9sbCBmb3IgV0cgYWRvcHRpb24g YW5kIElQUiBjaGVjayBmb3INCj4gZHJhZnQtbmFydGVuLW52bzMtYXJjaC0wMS50eHRdDQo+IA0K PiBMaW5kYSwNCj4gDQo+ID4gSWYgbW9zdCBUU2VzIGFyZSBvbmx5IGF0dGFjaGVkIHRvIGEgc2lu Z2xlIE5WRSBhbmQgdHJhZmZpYyB0byBOVkVzDQo+ID4gIGFyZSBub3QgYWdncmVnYXRlZCBmbG93 cywgdGhlbiB0aGUgTlZFLU5WRSBjb250cm9sIHBsYW5lIHByb3RvY29sDQo+ID4gIGRvZXNu4oCZ dCBwcm92aWRlIG11Y2ggYmVuZWZpdHMuDQo+IA0KPiBJIHdhbnQgdG8gZmxhZyB0aGUgZmlyc3Qg cGFydCBvZiB0aGUgc2VudGVuY2UgYWJvdmUgYmVjYXVzZSB0aGlzDQo+IHF1ZXN0aW9uIGhhcyBi ZWVuIHJhaXNlZCBiZWZvcmUuIEl0IHN1Z2dlc3RzIHRoYXQgYSBUUyBtaWdodCBjb25uZWN0DQo+ IHRvIG1vcmUgdGhhbiBvbmUgTlZFIGF0IGEgdGltZS4NCj4gDQo+IEZyb20gYW4gYXJjaGl0ZWN0 dXJhbCBwZXJwc2VjdGl2ZSwgSSB0aGluayB3ZSBzaG91bGQgc2F5ICJubyIuIExpZmUgaXMNCj4g bXVjaCBzaW1wbGVyIGlmIGEgVFMgY29ubmVjdHMgdG8gYSBWTiB0aHJvdWdoIGV4YWN0bHkgb25l IE5WRS4gTW9yZQ0KPiBwcmVjaXNlbHksIGEgVFNJIGFsd2F5cyBjb25uZWN0cyB0byBvbmUgTlZF LiBJZiB3ZSBhbGxvd2VkIGNvbm5lY3Rpb25zDQo+IHRvIG11bHRwbGUgTlZFcyBzaW11bHRhbmVv dXNseSwgaXQgd291bGQgcmFpc2UgYWxsIHNvcnRzIG9mIHF1ZXN0aW9ucw0KPiBhcyB0byB3aGVu IHRvIHVzZSBvbmUgb3ZlciB0aGUgb3RoZXIsIGV0Yy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgSSdt IGFjdHVhbGx5IHNheWluZyBhbnl0aGluZyBuZXcgd2l0aCB0aGlzLi4uIEkndmUNCj4gYWx3YXlz IGFzc3VtZWQgdGhpcywgZG9jdW1lbnRzIGFyZSB3cml0dGVuIHdpdGggdGhpcyBpbiBtaW5kLCBh bmQgaXQNCj4gaGFzbid0IGNvbWUgdXAgKG90aGVyIHRoYW4gaW4gcGFzc2luZykgb24gdGhlIGxp c3QuDQo+IA0KPiBBIFRTIGNhbiBzdGlsbCBjb25uZWN0IHRvIG11bHRpcGxlIGRpZmZlcmVudCBW TnMgdGhyb3VnaCBkaWZmZXJlbnQNCj4gbmV0d29yayBpbnRlcmZhY2VzLCBhbmQgaGVuY2UgZGlm ZmVyZW50IFRTSXMsIGJ1dCBJIHRoaW5rIHdlIHNob3VsZA0KPiBoYXZlIGEgVFNJIGFsd2F5cyBj b25uZWN0IHRvIGV4YWN0bHkgb25lIE5WRS4NCj4gDQo+IEFueSBvdGhlciBvcGluaW9ucz8NCj4g DQo+IFRob21hcw0KPiANCg0K From farinacci@gmail.com Wed Nov 20 10:11:02 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5028F1AE0CD for ; Wed, 20 Nov 2013 10:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3bpTEe8jZ1y for ; Wed, 20 Nov 2013 10:11:00 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A35A81AE02C for ; Wed, 20 Nov 2013 10:11:00 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so3858969pbb.4 for ; Wed, 20 Nov 2013 10:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RwfcbF58T586hYVvamJEuZ6eYAba5PeyuU9LnG97t2Q=; b=f1ycvICzPEVtmmu+f2K+lmd81TKOMlv6ZoonJ6oJp2sRENulJqFPpL9vrvvDgTJtA9 P/rSu3tom32RgiPJs3s0N69z6LH2ps5NflYI/2UOiXF8diQj5J0YuLyWPuzH7uNOj4AH tWUaTRiqx6CEqE7Y4NZOh8vG9jX2TqYQ3fQPs/6/PTrzHPd+AW9zWhL8iWT2R3VQEzc6 aaMpIljAH/Cte9z1mYWgEXMpRwcUSKmPL8XtfGq7g2duetwvk+NjbQ2jLi/XAsDqs8Ia ljygTjzVDJLOAvqYALaqy2YZcj3+NDXmO1pQ7coVeq34FvKA5jVeJhXNHI9Yj0a6aOFi GDLA== X-Received: by 10.68.219.72 with SMTP id pm8mr2032511pbc.164.1384971054354; Wed, 20 Nov 2013 10:10:54 -0800 (PST) Received: from [192.168.1.101] ([207.145.253.66]) by mx.google.com with ESMTPSA id bl8sm34661518pad.17.2013.11.20.10.10.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 10:10:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> Date: Wed, 20 Nov 2013 10:10:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org, Linda Dunbar Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 18:11:02 -0000 "Dino, >=20 >> Thomas, just be aware that in the physical case, a server is dual >> attached to multiple TORs. If each TOR is going to be an NVE, >> because you want to save state in the data center core layer, then >> you'll have to do multi-homing. >=20 > I suspect we need to dive a bit deeper into this. i.e., what does > "dual attached" mean? A bare-metal server has 2 physical connections to different boxes (where = a box is a swtich or a router). In some cases, the 2 connections are = active/active, but mostly active/backup. There is some assumption from = the server OSes that the upstream boxes are layer-2 switches. But it = doesn't have to be the case, they can be layer-3 routers. =20 > Do you mean the NVE has two physical connections to the ToR? If so, No, that would be the NVE being able to get ECMP support from the = underlay. I am talking about the NVE in the TOR, as one example. > than the question presumably is about allowing/supporting multi-homed > NVEs. That is right Thomas. > If the question is about the TS having two attachements to the ToR, > wouldn't that be modeled (architecturally) as two distinct > interfaces/ports, in which case each one can connect to its own NVE, > in which case we are good? The questions is about the return traffic coming to the TS. Do you want = it load-split across all the NVEs associated with the TS. The answer is = a definite yes, as Joel stated for robustness and to take advantage of = all cross-sectional cheap bandwidth in a data center. Dino >=20 > Thomas From narten@us.ibm.com Wed Nov 20 11:59:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B42D1AE09B for ; Wed, 20 Nov 2013 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3iGXi13KHmy for ; Wed, 20 Nov 2013 11:59:49 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 609231AE071 for ; Wed, 20 Nov 2013 11:59:49 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 14:59:42 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 14:59:40 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 753CDC90043 for ; Wed, 20 Nov 2013 14:59:38 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKJxdJv5767544 for ; Wed, 20 Nov 2013 19:59:39 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKJxdqI030489 for ; Wed, 20 Nov 2013 14:59:39 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKJxcv2030379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 14:59:39 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKJxbXe007752; Wed, 20 Nov 2013 14:59:37 -0500 Message-Id: <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> To: Dino Farinacci In-reply-to: <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Wed, 20 Nov 2013 10:10:51 -0800." Date: Wed, 20 Nov 2013 14:59:36 -0500 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112019-7182-0000-0000-0000092A485C Cc: nvo3@ietf.org Subject: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 19:59:51 -0000 Hi Dino. > > I suspect we need to dive a bit deeper into this. i.e., what does > > "dual attached" mean? > A bare-metal server has 2 physical connections to different boxes > (where a box is a swtich or a router). In some cases, the 2 > connections are active/active, but mostly active/backup. There is > some assumption from the server OSes that the upstream boxes are > layer-2 switches. But it doesn't have to be the case, they can be > layer-3 routers. I think there are multiple scenarios here to consider, and the details matter. Scenario 1: Bare metal server has 2 separate connections to two different boxes. How are these two connections presented to the (bare-metal) TS? 1A) two different interfaces are visible to the TS, both with their own separate IP addresses. This is not an issue for NVO3, since this is modeled as two interfaces to two separate VNs. (Right?) B) TS sees only one interface, the CNA hides the details of two physical uplinks from TS. Links could be active/active or active/backup. In this case, the TS has one IP adddress (I presume) with the CNA hiding the details of multiple uplinks from the TS. This is a messier case... Do both uplinks have to connect to the same NVE? In the standard L2 case, don't both L2 uplinks have to connect to the "same L2 network"? That only means that both ToRs would need to support the same VLANs and connect to the same LAN domains. (Right?) If above we allow the two uplinks to go to two different NVEs, the implication is that from an NVO3 perspective, a given TS mapping is reachable through different NVE addresses. That raises all sorts of interesting questions. :-) > > Do you mean the NVE has two physical connections to the ToR? If so, > No, that would be the NVE being able to get ECMP support from the > underlay. I am talking about the NVE in the TOR, as one example. Right, NVE is doing IP and each uplink would be to different L3 dest. > > than the question presumably is about allowing/supporting multi-homed > > NVEs. > That is right Thomas. Yikes. I guess we need to have that discussion. :) > > If the question is about the TS having two attachements to the ToR, > > wouldn't that be modeled (architecturally) as two distinct > > interfaces/ports, in which case each one can connect to its own NVE, > > in which case we are good? > The questions is about the return traffic coming to the TS. Do you > want it load-split across all the NVEs associated with the TS. The > answer is a definite yes, as Joel stated for robustness and to take > advantage of all cross-sectional cheap bandwidth in a data center. Fundamentally, it means that address mappings (inner to outer) are not one-to-one, but are one-to-many. Is this something we need to support? I agree it has some benefits. But it also adds some complications... Thomas From farinacci@gmail.com Wed Nov 20 13:55:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76D1AE582 for ; Wed, 20 Nov 2013 13:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH16UVoRTYxL for ; Wed, 20 Nov 2013 13:55:50 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id E1C401AE581 for ; Wed, 20 Nov 2013 13:55:49 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so2561213pdj.26 for ; Wed, 20 Nov 2013 13:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pJ4+y3q/rmfID6p06nOob6LSFnnSZskOCXumGqU4Uvc=; b=cEdBRbJKWx6gfcZV3K/qjAq8XbOkXBdrRdbT1YtRowYABq/geldUxPrJgY0bH1SInu 2pYb9RCnzWc32ttMs5QXIe8n9etV/29ugexZFk0VHraBwnOzBqqi/KzAs38hGMVwpImE QcJROsmyp/i19K+Zu5u3YPxQcSWNgH5din10hSDisH57Z6ewMG6G3s3L0VxyfBSgclP/ sPvCsVbMCWUOvlkFb1QWAFEFZau2f1ZgEE6AjpF+tnwCqr3fo7loigdSgdUJcTMjP3r+ liaANj62e8emGkOHHY9ZVRhB6/NfFo6HGDAZaZeDYj0hHL5q5Tzb+B/Y92E0cc8ahfSW rd6A== X-Received: by 10.68.217.129 with SMTP id oy1mr2836178pbc.23.1384984543522; Wed, 20 Nov 2013 13:55:43 -0800 (PST) Received: from [192.168.1.5] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id oa3sm7251241pbb.15.2013.11.20.13.55.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 13:55:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> Date: Wed, 20 Nov 2013 13:55:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 21:55:51 -0000 > I think there are multiple scenarios here to consider, and the details > matter. Agree. > Scenario 1: Bare metal server has 2 separate connections to two > different boxes. How are these two connections presented to the > (bare-metal) TS? I am going to fail at describing this with the NVO3 terminology. A TS to = me is a site, that has lots of hosts, switches, routers in it. They are = addressable. I call those addresses EIDs. So we are talking about a = single EID. An IP address assigned to a bare-metal server that has two = connections, one to each physical NVE. > 1A) two different interfaces are visible to the TS, both with their > own separate IP addresses. This is not an issue for NVO3, since this > is modeled as two interfaces to two separate VNs. (Right?) I can't answer this because I am not sure you and I agree on what a TS = is. I am not disagreeing how NVO3 defines a TS but I think it is not = specific enough for this context. > B) TS sees only one interface, the CNA hides the details of two > physical uplinks from TS. Links could be active/active or > active/backup. In this case, the TS has one IP adddress (I presume) > with the CNA hiding the details of multiple uplinks from the TS. >=20 > This is a messier case... Do both uplinks have to connect to the same > NVE? In the standard L2 case, don't both L2 uplinks have to connect to > the "same L2 network"? That only means that both ToRs would need to > support the same VLANs and connect to the same LAN domains. (Right?) Yes, they have to connect to the same L2 network. > If above we allow the two uplinks to go to two different NVEs, the > implication is that from an NVO3 perspective, a given TS mapping is > reachable through different NVE addresses. That raises all sorts of > interesting questions. :-) This called multi-homing. ;-) That is equivalent to a LISP EID that = has a locator-set. The reason there is a locator-set is because there = can be multiple RLOCs (read: NVEs) used reach the EID. > Do you mean the NVE has two physical connections to the ToR? If so, No, I am simply generalizing it to this topology: EIDs / \ / \ NVE NVE / \ / \ Where there are multiple from the EID to 1-or-more NVEs. And the NVEs = have multiple paths leading to the core. > No, that would be the NVE being able to get ECMP support from the >> underlay. I am talking about the NVE in the TOR, as one example. >=20 > Right, NVE is doing IP and each uplink would be to different L3 dest. >=20 >>> than the question presumably is about allowing/supporting = multi-homed >>> NVEs. >=20 >> That is right Thomas. >=20 > Yikes. I guess we need to have that discussion. :) >=20 >>> If the question is about the TS having two attachements to the ToR, >>> wouldn't that be modeled (architecturally) as two distinct >>> interfaces/ports, in which case each one can connect to its own NVE, >>> in which case we are good? >=20 >> The questions is about the return traffic coming to the TS. Do you >> want it load-split across all the NVEs associated with the TS. The >> answer is a definite yes, as Joel stated for robustness and to take >> advantage of all cross-sectional cheap bandwidth in a data center. >=20 > Fundamentally, it means that address mappings (inner to outer) are not > one-to-one, but are one-to-many. That is correct. And many-to-one as well. > Is this something we need to support? I agree it has some > benefits. But it also adds some complications... >=20 > Thomas It depends how close topologically the NVE is to the endpoint. If the = NVE was in the application, then for the same IP address there would be = multiple NVEs. So the point could be taken to an extreme. Dino From narten@us.ibm.com Wed Nov 20 14:09:14 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06C71AE16F for ; Wed, 20 Nov 2013 14:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UA1AH-7OP4sL for ; Wed, 20 Nov 2013 14:09:12 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6080B1AE028 for ; Wed, 20 Nov 2013 14:09:12 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 17:09:05 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 17:09:03 -0500 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D223F38C8047 for ; Wed, 20 Nov 2013 17:09:01 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKM93iU1245646 for ; Wed, 20 Nov 2013 22:09:03 GMT Received: from d01av01.pok.ibm.com (localhost [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKM92iB012728 for ; Wed, 20 Nov 2013 17:09:03 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d01av01.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKM91bB012554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 17:09:02 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKM8xXB025807; Wed, 20 Nov 2013 17:09:00 -0500 Message-Id: <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> To: Dino Farinacci In-reply-to: <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Wed, 20 Nov 2013 13:55:38 -0800." Date: Wed, 20 Nov 2013 17:08:59 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112022-0320-0000-0000-000001C9DC51 Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:09:14 -0000 Dino Farinacci writes: > > Scenario 1: Bare metal server has 2 separate connections to two > > different boxes. How are these two connections presented to the > > (bare-metal) TS? > I am going to fail at describing this with the NVO3 terminology. A > TS to me is a site, that has lots of hosts, switches, routers in > it. They are addressable. I call those addresses EIDs. So we are > talking about a single EID. An IP address assigned to a bare-metal > server that has two connections, one to each physical NVE. A TS is Tenant System. E.g., a VM on virtualized host, or the bare metal server in your original example. The NVE is normally very close to the TS, i.e., on the same server, or offloaded to the ToR. > > 1A) two different interfaces are visible to the TS, both with their > > own separate IP addresses. This is not an issue for NVO3, since this > > is modeled as two interfaces to two separate VNs. (Right?) > I can't answer this because I am not sure you and I agree on what a > TS is. I am not disagreeing how NVO3 defines a TS but I think it is > not specific enough for this context. TS is a single host endpoint. It connects directly to a virtual network through an NVE. > > B) TS sees only one interface, the CNA hides the details of two > > physical uplinks from TS. Links could be active/active or > > active/backup. In this case, the TS has one IP adddress (I presume) > > with the CNA hiding the details of multiple uplinks from the TS. > > > > This is a messier case... Do both uplinks have to connect to the same > > NVE? In the standard L2 case, don't both L2 uplinks have to connect to > > the "same L2 network"? That only means that both ToRs would need to > > support the same VLANs and connect to the same LAN domains. (Right?) > Yes, they have to connect to the same L2 network. The difference is in the L2 case, you can send a packet up either uplink and things generally work (you may still have to deal with MAC flapping concerns). In the NVO3 case, if the two upstream NVEs are different, they will have their own IP addresses and the tunnel source for packets they send to remote NVEs will be different depending on which NVE is the sender. > > If above we allow the two uplinks to go to two different NVEs, the > > implication is that from an NVO3 perspective, a given TS mapping is > > reachable through different NVE addresses. That raises all sorts of > > interesting questions. :-) > This called multi-homing. ;-) That is equivalent to a LISP EID that > has a locator-set. The reason there is a locator-set is because > there can be multiple RLOCs (read: NVEs) used reach the EID. Right. The WG just hasn't had much discussion about whether NVEs need to be multi-homed. So we don't really have a position yet. > > Is this something we need to support? I agree it has some > > benefits. But it also adds some complications... > > > > Thomas > It depends how close topologically the NVE is to the endpoint. If > the NVE was in the application, then for the same IP address there > would be multiple NVEs. So the point could be taken to an extreme. In the virtualized case, the NVE is on the same server as the VM/TS. In the bare metal case, the NVE is offloaded onto an adjacent device (e.g., ToR), but is still quite close. Thomas From farinacci@gmail.com Wed Nov 20 14:27:30 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0AB1AE4F0 for ; Wed, 20 Nov 2013 14:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAPUSgnZ7pVa for ; Wed, 20 Nov 2013 14:27:28 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 424361AE419 for ; Wed, 20 Nov 2013 14:27:28 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so4149720pbc.21 for ; Wed, 20 Nov 2013 14:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qyBSii1nabyGDmTqZvkWUTorhG4Xqq7C4JsMAFrLP1Y=; b=HBiwKBSGDBtGTzvSZH+Ux2WTRg9TG5Nu1xvbpc74F5C0TCbwLp923dWRKeGGpiBomT m9OIu2eCFMl7pS1iUPOptWhXWo7z1JoF5/2zwZQj9kTtPx6PQOp6Zmf2HtLlYE/nAGxW T9nHf8Vk+p+rVmS8tpcCgsx5elJfcbUTYosQd3fYEOhwZNRflP+EtSUmWJ8jFag7ISOt kN7WKV1YBBo7p8p0kyPkAYy1OaSTJ5wEDb4sCT5pk54x8bU3xofjB7UjDELHmzEZlSnE rL51hAh6GbTbk1b/eYfaHHmeZi3B6XduFJnqSmSxTtmhCacRT8aJrvkG1+Nh/S6ormrO SAmA== X-Received: by 10.66.249.202 with SMTP id yw10mr2880846pac.111.1384986441876; Wed, 20 Nov 2013 14:27:21 -0800 (PST) Received: from [192.168.1.5] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id xn12sm45848752pac.12.2013.11.20.14.27.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 14:27:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> Date: Wed, 20 Nov 2013 14:27:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:27:30 -0000 > Dino Farinacci writes: >=20 >>> Scenario 1: Bare metal server has 2 separate connections to two >>> different boxes. How are these two connections presented to the >>> (bare-metal) TS? >=20 >> I am going to fail at describing this with the NVO3 terminology. A >> TS to me is a site, that has lots of hosts, switches, routers in >> it. They are addressable. I call those addresses EIDs. So we are >> talking about a single EID. An IP address assigned to a bare-metal >> server that has two connections, one to each physical NVE. >=20 > A TS is Tenant System. E.g., a VM on virtualized host, or the bare > metal server in your original example.=20 >=20 > The NVE is normally very close to the TS, i.e., on the same server, or > offloaded to the ToR. I know of deployments where the NVE equivalent is at the end-of-row = router. >=20 >>> 1A) two different interfaces are visible to the TS, both with their >>> own separate IP addresses. This is not an issue for NVO3, since this >>> is modeled as two interfaces to two separate VNs. (Right?) >=20 >> I can't answer this because I am not sure you and I agree on what a >> TS is. I am not disagreeing how NVO3 defines a TS but I think it is >> not specific enough for this context. >=20 > TS is a single host endpoint. It connects directly to a virtual > network through an NVE. What do you call a multi-tenant rack? In deployments, a tenant is a = customer of the provider where there are many 'systems' in the tenant, = each with one or more IP addresses assigned to them. >=20 >>> B) TS sees only one interface, the CNA hides the details of two >>> physical uplinks from TS. Links could be active/active or >>> active/backup. In this case, the TS has one IP adddress (I presume) >>> with the CNA hiding the details of multiple uplinks from the TS. >>>=20 >>> This is a messier case... Do both uplinks have to connect to the = same >>> NVE? In the standard L2 case, don't both L2 uplinks have to connect = to >>> the "same L2 network"? That only means that both ToRs would need to >>> support the same VLANs and connect to the same LAN domains. (Right?) >=20 >> Yes, they have to connect to the same L2 network. >=20 > The difference is in the L2 case, you can send a packet up either > uplink and things generally work (you may still have to deal with MAC > flapping concerns). In the NVO3 case, if the two upstream NVEs are > different, they will have their own IP addresses and the tunnel source > for packets they send to remote NVEs will be different depending on > which NVE is the sender. Sending is not the interesting case and is a bit off topic. It is return = packets and which (or both) NVEs is used as the target of encapsulation. >=20 >>> If above we allow the two uplinks to go to two different NVEs, the >>> implication is that from an NVO3 perspective, a given TS mapping is >>> reachable through different NVE addresses. That raises all sorts of >>> interesting questions. :-) >=20 >> This called multi-homing. ;-) That is equivalent to a LISP EID that >> has a locator-set. The reason there is a locator-set is because >> there can be multiple RLOCs (read: NVEs) used reach the EID. >=20 > Right. >=20 > The WG just hasn't had much discussion about whether NVEs need to be > multi-homed. So we don't really have a position yet. Yes, right, why we are bringing it up now. >=20 >>> Is this something we need to support? I agree it has some >>> benefits. But it also adds some complications... >>>=20 >>> Thomas >=20 >> It depends how close topologically the NVE is to the endpoint. If >> the NVE was in the application, then for the same IP address there >> would be multiple NVEs. So the point could be taken to an extreme. >=20 > In the virtualized case, the NVE is on the same server as the > VM/TS. In the bare metal case, the NVE is offloaded onto an adjacent > device (e.g., ToR), but is still quite close. >=20 > Thomas You are assuming a specific implementation of an NVE and where it = resides. That should be be assumed in the architecture IMO. Dino From narten@us.ibm.com Wed Nov 20 14:36:21 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20961AE148 for ; Wed, 20 Nov 2013 14:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcA4PntzoRS4 for ; Wed, 20 Nov 2013 14:36:19 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2211AE0C1 for ; Wed, 20 Nov 2013 14:36:19 -0800 (PST) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Nov 2013 15:36:12 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 20 Nov 2013 15:36:11 -0700 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 697DE19D804C for ; Wed, 20 Nov 2013 15:36:05 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by b03cxnp07028.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAKKYBF52490786 for ; Wed, 20 Nov 2013 21:34:11 +0100 Received: from d03av03.boulder.ibm.com (localhost [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAKMa9po014879 for ; Wed, 20 Nov 2013 15:36:10 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-49-155-99.mts.ibm.com [9.49.155.99]) by d03av03.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAKMa8jZ014756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Nov 2013 15:36:09 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAKMa75H029768; Wed, 20 Nov 2013 17:36:07 -0500 Message-Id: <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> To: Dino Farinacci In-reply-to: <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Wed, 20 Nov 2013 14:27:17 -0800." Date: Wed, 20 Nov 2013 17:36:07 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112022-1542-0000-0000-00000378208C Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:36:21 -0000 Dino Farinacci writes: > > The NVE is normally very close to the TS, i.e., on the same server, or > > offloaded to the ToR. > I know of deployments where the NVE equivalent is at the end-of-row > router. But lets deal with the common/expected case. That starts with NVEs co-located with the hypervisors. One important reason that NVEs tend to be close to the TS is that you can deploy things that way with little or no change to the underlay. > > TS is a single host endpoint. It connects directly to a virtual > > network through an NVE. > What do you call a multi-tenant rack? In deployments, a tenant is a > customer of the provider where there are many 'systems' in the > tenant, each with one or more IP addresses assigned to them. Different kind of tenant. If you have a tenant (say coke) that has a virtual network with (say) 100 VMs on it that talk to each other, each VM is a TS and connects to an NVE. > Sending is not the interesting case and is a bit off topic. It is > return packets and which (or both) NVEs is used as the target of > encapsulation. Agree... > > > >>> Is this something we need to support? I agree it has some > >>> benefits. But it also adds some complications... > >>> > >>> Thomas > > > >> It depends how close topologically the NVE is to the endpoint. If > >> the NVE was in the application, then for the same IP address there > >> would be multiple NVEs. So the point could be taken to an extreme. > > > > In the virtualized case, the NVE is on the same server as the > > VM/TS. In the bare metal case, the NVE is offloaded onto an adjacent > > device (e.g., ToR), but is still quite close. > > > > Thomas > You are assuming a specific implementation of an NVE and where it > resides. That should be be assumed in the architecture IMO. You presumably mean "should not be assumed". Well, the truth is that NVEs have been assumed to be close to the TS from day one... And one reason is that if you push the NVE out further and further away from the TS, it adds complications. We shouldn't do that unless necessary. Thomas From farinacci@gmail.com Wed Nov 20 14:58:50 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864AC1AE198 for ; Wed, 20 Nov 2013 14:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1n7V6fvRKyd for ; Wed, 20 Nov 2013 14:58:48 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEF1AE0CF for ; Wed, 20 Nov 2013 14:58:48 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so4172330pbc.41 for ; Wed, 20 Nov 2013 14:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9uKSTc0XP9nzYcQQ2ZTt22LrWUno3g90kj3AFKB/Ato=; b=MfJbNqJ8xa9CYsn7+1Y5Oh8pplVADWYFmivPyX7Y4T2b3mztsV7TL6fmUeAA//MI/u /QCho2eLtG9jhO4FORWr8bv3HSJVGUTzhaUFpfGimC8HNvyHJ9z0Za8otj+STCRxDvyP dOKuF9R65uv0X6DD/8atHalXW4nI/LprOZm+xkS7CLoAhTTIaEv9GS3uKLdgWHwst7eA gKbWWwgnSWJHDS+4YSbVIo9trbomvXR36k+bDPI6NwJiNcSg/auWun2WJyl7pK4UUsaF p5d/LQTPp978xZmRa+6GxFV/Ojb8sfEPWpN7IwCqhzyuHOlcnV32w0ADkPyzeAxgh3X8 XHyA== X-Received: by 10.66.102.66 with SMTP id fm2mr3130682pab.94.1384988322504; Wed, 20 Nov 2013 14:58:42 -0800 (PST) Received: from [192.168.1.5] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id zq10sm45995278pab.6.2013.11.20.14.58.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 14:58:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> Date: Wed, 20 Nov 2013 14:58:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <083F852A-1B2C-4271-A275-5D9490C33BC1@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:58:50 -0000 Dino Farinacci writes: >=20 >>> The NVE is normally very close to the TS, i.e., on the same server, = or >>> offloaded to the ToR. >=20 >> I know of deployments where the NVE equivalent is at the end-of-row >> router. >=20 > But lets deal with the common/expected case. That starts with NVEs > co-located with the hypervisors. Why is that an expected case? I guess host vendors or software-only = vendors would appreciate that but I'm sure equipment vendors would not. > One important reason that NVEs tend to be close to the TS is that you > can deploy things that way with little or no change to the underlay. At the cost of lost aggregation. There are pros and cons either way. >> TS is a single host endpoint. It connects directly to a virtual >>> network through an NVE. >=20 >> What do you call a multi-tenant rack? In deployments, a tenant is a >> customer of the provider where there are many 'systems' in the >> tenant, each with one or more IP addresses assigned to them. >=20 > Different kind of tenant. If you have a tenant (say coke) that has a > virtual network with (say) 100 VMs on it that talk to each other, each > VM is a TS and connects to an NVE. It is is a VPN with say 10 sites, each with your 10 VMs, then each site = could share an NVE. > Sending is not the interesting case and is a bit off topic. It is >> return packets and which (or both) NVEs is used as the target of >> encapsulation. >=20 > Agree... >=20 >>>=20 >>>>> Is this something we need to support? I agree it has some >>>>> benefits. But it also adds some complications... >>>>>=20 >>>>> Thomas >>>=20 >>>> It depends how close topologically the NVE is to the endpoint. If >>>> the NVE was in the application, then for the same IP address there >>>> would be multiple NVEs. So the point could be taken to an extreme. >>>=20 >>> In the virtualized case, the NVE is on the same server as the >>> VM/TS. In the bare metal case, the NVE is offloaded onto an adjacent >>> device (e.g., ToR), but is still quite close. >>>=20 >>> Thomas >=20 >> You are assuming a specific implementation of an NVE and where it >> resides. That should be be assumed in the architecture IMO. >=20 > You presumably mean "should not be assumed". Yes, that was a typo. > Well, the truth is that NVEs have been assumed to be close to the TS > from day one... And one reason is that if you push the NVE out further > and further away from the TS, it adds complications. We shouldn't do > that unless necessary. >=20 > Thomas You can see by now is that my point is that architecturally you = shouldn't say where NVEs are or how they are implemented (in software, = hardware or combo software/hardware). I will argue that if you push an NVE further out there are less of them = to manage so you get OpEx benefits. Dino From Lothar.Reith@detecon.com Wed Nov 20 16:03:35 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C01AE12B for ; Wed, 20 Nov 2013 16:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G--NXA_noHQo for ; Wed, 20 Nov 2013 16:03:32 -0800 (PST) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by ietfa.amsl.com (Postfix) with ESMTP id 572A61AE116 for ; Wed, 20 Nov 2013 16:03:32 -0800 (PST) Received: from unknown (HELO dc312v.detecon.com) ([172.16.6.75]) by relay.dtc034.detecon.net with ESMTP; 21 Nov 2013 01:03:24 +0100 Received: from DC301.detecon.com ([fe80::b0b0:66e7:2cac:ab91]) by dc312v.detecon.com ([::1]) with mapi id 14.02.0328.009; Thu, 21 Nov 2013 01:03:24 +0100 From: "Reith, Lothar" To: Dino Farinacci , Thomas Narten Thread-Topic: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] Thread-Index: AQHO5hO5/oNdwAj0u0ih8SnYD7LzApouTduAgAAB4gCAAAsIgIAAXdxQ Date: Thu, 21 Nov 2013 00:03:22 +0000 Message-ID: References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> In-Reply-To: <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.213.155] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 00:03:35 -0000 Dear friends, are we sure everybody is on the same page? Please make sure we are all talk= ing about use case a) below when we use the term "multi-homing", and not re= ferring to use cases b),c) or even d). Two physical links from a bare metal server representing the equivalent of = a single VM interfacing to two different physical devices can be implemente= d in the following use case scenarios: a). Layer 3 Multihoming with two different underlying layer 2 networks (i.e= . the VM or bare metal server has two different TSIs each interfacing to a = different Gateway IP) b). Layer 3 VRRP based Gateway redundancy with both physical links being pa= rt of the same layer 2 network, which has 3 endpoints, however 2 of them sh= are the same MAC and IP address which floats between the two physical devic= es as virtual IP address and virtual MAC address of one virtual gateway tha= t is redundant because it is distributed/split across two physical devices.= In order not to be confused with the term distributed gateway, this redund= ant gateway can be one local portion of a distributed gateway in the previo= usly discussed sense, where the portions of the distributed gateway may eve= n be distributed across multiple autonomous systems (if I understand this c= orrectly). c). Layer 2 bonding/Link aggregation based with LACP controlled active/pass= ive mode or less likely also supporting active/active mode: Both Tenant sys= tem sided physical link endpoints are a member of a normal LAG (bonding gro= up), while both corresponding NVE sided physical link endpoints are also bo= nded together to form a single MAC-Service Access Point using a potentially= proprietary multichassis LAG implementation, where the control plane for c= ross-synchronization between both NVE sided endpoints may be via Layer3 or = via Layer2, and where implementations may be vendor specific and differ wit= h respect to whether the NVE is one logical device distributed across two p= hysical devices, or two logical NVE devices (one per physical device). In a= ny case both physical devices are cooperating somehow to pretend to the oth= er side of the point to point layer 2 network that they implement a single = aggregated layer 2 interface (most likely only supporting active/passive mo= de where only one of the two physical links is active carrying user plane t= raffic at any one time). d). For completeness: Layer 1 bonding is also possible, but might be neglec= ted here. Lothar -----Urspr=FCngliche Nachricht----- Von: nvo3 [mailto:nvo3-bounces@ietf.org] Im Auftrag von Dino Farinacci Gesendet: Mittwoch, 20. November 2013 19:11 An: Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Betreff: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for N= VE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-= narten-nvo3-arch-01.txt] "Dino, >=20 >> Thomas, just be aware that in the physical case, a server is dual >> attached to multiple TORs. If each TOR is going to be an NVE, >> because you want to save state in the data center core layer, then >> you'll have to do multi-homing. >=20 > I suspect we need to dive a bit deeper into this. i.e., what does > "dual attached" mean? A bare-metal server has 2 physical connections to different boxes (where a = box is a swtich or a router). In some cases, the 2 connections are active/a= ctive, but mostly active/backup. There is some assumption from the server O= Ses that the upstream boxes are layer-2 switches. But it doesn't have to be= the case, they can be layer-3 routers. =20 > Do you mean the NVE has two physical connections to the ToR? If so, No, that would be the NVE being able to get ECMP support from the underlay.= I am talking about the NVE in the TOR, as one example. > than the question presumably is about allowing/supporting multi-homed > NVEs. That is right Thomas. > If the question is about the TS having two attachements to the ToR, > wouldn't that be modeled (architecturally) as two distinct > interfaces/ports, in which case each one can connect to its own NVE, > in which case we are good? The questions is about the return traffic coming to the TS. Do you want it = load-split across all the NVEs associated with the TS. The answer is a defi= nite yes, as Joel stated for robustness and to take advantage of all cross-= sectional cheap bandwidth in a data center. Dino >=20 > Thomas _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Wed Nov 20 16:07:09 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462181AE1E9 for ; Wed, 20 Nov 2013 16:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMRexrHm_SkB for ; Wed, 20 Nov 2013 16:07:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5075E1AE12B for ; Wed, 20 Nov 2013 16:07:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD60653; Thu, 21 Nov 2013 00:06:57 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 00:06:44 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 00:06:55 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 16:06:47 -0800 From: Lucy yong To: Vivek Kumar , "Larry Kreeger (kreeger)" , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAAI/akA== Date: Thu, 21 Nov 2013 00:06:46 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF555@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 00:07:09 -0000 Sorry to chip in. See inline below. -----Original Message----- From: Vivek Kumar [mailto:kvivek@broadcom.com]=20 Sent: Wednesday, November 20, 2013 12:00 AM To: Larry Kreeger (kreeger); Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Larry, Consider following diagram .=20 TS1->NVE1->L3 network ->NVE2->TS2 . [Lucy] The given example is L3 VN. Both NVE1 and NVE2 are the member of the= L3VN. NVE2 just decapsulates it and forward to TS2. No service needs to pr= ovide at egress. In the case, the VAP interface between TS2-NVE2 is VLAN in= terface, NVE2 learns the TS2 MAC address ahead and inserts the TS2 MAC as t= he dst MAC and its MAC as its src MAC prior sending to TS2. If the VAP is t= he IP interface, NVE2 forward the packet directly to TS2. Lucy =20 Now , I can have L2/L3 services between TS attached to NVE1 and NVE2 . Lucy= comment clearly explains how NVE1 will detect whether to perform L2 or L3 = services for Tenant frame . My question is when NVE2 decapsulates the packe= t , how it will know which service to provide .=20 Let me know if I am still not clear. Regards, Vivek -----Original Message----- From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Wednesday, November 20, 2013 10:45 AM To: Vivek Kumar; Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Vivek, Can you explain what you mean? We are discussing the service provided to t= he TS. How would it look different to the TS for "L2 serviced or L3 servic= ed when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how=20 >to detect if Tenant Frame has to be L2 serviced or L3 serviced when=20 >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the=20 >broadcast/multicast packet should be sent to another VN is depend on=20 >inter VN policy. It is possible. When the broadcast/multicast packet=20 >deliver to the L3 router too. If the policy allows the=20 >broadcast/multicast to broadcast to another VN, L3 router will forward=20 >the packet to another VN with the same DMAC. If the policy does not=20 >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send=20 >to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3=20 >treatment. > An NVE receiving packets from a TS determines the type of=20 >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a=20 >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the=20 >inter-VN policy, > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 >header (as well > as Ethernet header) . A combined L2/L3 service presents no=20 >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead=20 >the router receives all of them and processes them based on the L3=20 >multicast FIB. > >(For products which implement both L2 and L3 the processing of=20 >multicast depends on whether the input port is L2 or L3, and in some=20 >cases that will result in both bridging the packet out other L2 ports,=20 >and forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC=20 >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of=20 >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP=20 >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no=20 >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text=20 >> to make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to=20 >> have a combined L2/L3 service. Here is proposed text for the=20 >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply =20 >> > describing what we mean by a combined L2/L3 service. That is what=20 >> my >> > text was trying to do. The thinking is if the service definition is=20 >> > clear and simple, supporting it in NVO3 is not a problem. I.e.,=20 >> > it's not really much different to provide a combined service than=20 >> > if you offer an L2 or L3 service. And the service semantics for=20 >> > combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > =20 >> > Whether and how it makes sense to have distributed gateways in a >=20 >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if=20 >> > a distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined >=20 >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the=20 >> same > as taking the two separate L2 and L3 services and combining=20 >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where=20 >> we can easily get > into trouble is if we start defining a combined=20 >> service as has special > cases that have to be dealt with that don't=20 >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From Lothar.Reith@detecon.com Wed Nov 20 17:05:41 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282D61AC441 for ; Wed, 20 Nov 2013 17:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NOxmTx8L404 for ; Wed, 20 Nov 2013 17:05:37 -0800 (PST) Received: from dtc034.detecon.net (dtc034.detecon.net [194.25.60.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF3B1A802B for ; Wed, 20 Nov 2013 17:05:36 -0800 (PST) Received: from unknown (HELO dc312v.detecon.com) ([172.16.6.75]) by relay.dtc034.detecon.net with ESMTP; 21 Nov 2013 02:05:29 +0100 Received: from DC301.detecon.com ([fe80::b0b0:66e7:2cac:ab91]) by dc312v.detecon.com ([::1]) with mapi id 14.02.0328.009; Thu, 21 Nov 2013 02:05:28 +0100 From: "Reith, Lothar" To: Dino Farinacci , Thomas Narten Thread-Topic: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] Thread-Index: AQHO5lXEx/B1FZ8NUEOqNKXP5kN/cw== Date: Thu, 21 Nov 2013 01:05:28 +0000 Message-ID: References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.213.155] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 01:05:41 -0000 Just wanted to add that the terms "NIC-teaming", NIC-bonding","port-channel= " "LAG" "LACP" are all referring to case c) when combined with two physical= links towards two different physical devices implementing the NVE side (po= tentially vendor dependant either one NVE distributed across 2 physical dev= ices or two NVE. In any case, the single NVE or the both NVEs terminate th= e two physical links and hide the fact that they are two physical interface= s from their upper layers, by pretending they can be accessed like a single= physical interface, due to the fact that a single MAC-Service Access Point= is presented to the upper layers, which may switch locations when the acti= ve/passive sub-state changes. Kind of magic, but I am aware of at least 3 or 4 different vendor implement= ations of such multi-chassis LAG behavior.=20 And I like to note that some legacy OSS systems may have trouble coping wit= h logical devices distributed across multiple physical devices, making the = IT for provisioning and assurance quite expensive or suboptimal due to work= arounds being applied, which complicate things over time. Please keep in mind that at the end of the day, operators need to map the N= VE in their inventory systems, correlate alarms for assurance etc. It would= be a nightmare, if different vendors implement the obviously required NVE = redundancy in fundamentally different ways such as some vendors implementin= g an NVE in a way that his has one location, and another vendor where an NV= E has multiple locations. This may even lead to vendor specific assurance p= rocesses - an absolute No-Go for carriers if they are not insane. Lothar -----Urspr=FCngliche Nachricht----- Von: nvo3 [mailto:nvo3-bounces@ietf.org] Im Auftrag von Reith, Lothar Gesendet: Donnerstag, 21. November 2013 01:03 An: Dino Farinacci; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Betreff: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for N= VE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-= narten-nvo3-arch-01.txt] Dear friends, are we sure everybody is on the same page? Please make sure we are all talk= ing about use case a) below when we use the term "multi-homing", and not re= ferring to use cases b),c) or even d). Two physical links from a bare metal server representing the equivalent of = a single VM interfacing to two different physical devices can be implemente= d in the following use case scenarios: a). Layer 3 Multihoming with two different underlying layer 2 networks (i.e= . the VM or bare metal server has two different TSIs each interfacing to a = different Gateway IP) b). Layer 3 VRRP based Gateway redundancy with both physical links being pa= rt of the same layer 2 network, which has 3 endpoints, however 2 of them sh= are the same MAC and IP address which floats between the two physical devic= es as virtual IP address and virtual MAC address of one virtual gateway tha= t is redundant because it is distributed/split across two physical devices.= In order not to be confused with the term distributed gateway, this redund= ant gateway can be one local portion of a distributed gateway in the previo= usly discussed sense, where the portions of the distributed gateway may eve= n be distributed across multiple autonomous systems (if I understand this c= orrectly). c). Layer 2 bonding/Link aggregation based with LACP controlled active/pass= ive mode or less likely also supporting active/active mode: Both Tenant sys= tem sided physical link endpoints are a member of a normal LAG (bonding gro= up), while both corresponding NVE sided physical link endpoints are also bo= nded together to form a single MAC-Service Access Point using a potentially= proprietary multichassis LAG implementation, where the control plane for c= ross-synchronization between both NVE sided endpoints may be via Layer3 or = via Layer2, and where implementations may be vendor specific and differ wit= h respect to whether the NVE is one logical device distributed across two p= hysical devices, or two logical NVE devices (one per physical device). In a= ny case both physical devices are cooperating somehow to pretend to the oth= er side of the point to point layer 2 network that they implement a single = aggregated layer 2 interface (most likely only supporting active/passive mo= de where only one of the two physical links is active carrying user plane t= raffic at any one time). d). For completeness: Layer 1 bonding is also possible, but might be neglec= ted here. Lothar -----Urspr=FCngliche Nachricht----- Von: nvo3 [mailto:nvo3-bounces@ietf.org] Im Auftrag von Dino Farinacci Gesendet: Mittwoch, 20. November 2013 19:11 An: Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Betreff: Re: [nvo3] TS conects to VN through one NVE [was Re: No need for N= VE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-= narten-nvo3-arch-01.txt] "Dino, >=20 >> Thomas, just be aware that in the physical case, a server is dual >> attached to multiple TORs. If each TOR is going to be an NVE, >> because you want to save state in the data center core layer, then >> you'll have to do multi-homing. >=20 > I suspect we need to dive a bit deeper into this. i.e., what does > "dual attached" mean? A bare-metal server has 2 physical connections to different boxes (where a = box is a swtich or a router). In some cases, the 2 connections are active/a= ctive, but mostly active/backup. There is some assumption from the server O= Ses that the upstream boxes are layer-2 switches. But it doesn't have to be= the case, they can be layer-3 routers. =20 > Do you mean the NVE has two physical connections to the ToR? If so, No, that would be the NVE being able to get ECMP support from the underlay.= I am talking about the NVE in the TOR, as one example. > than the question presumably is about allowing/supporting multi-homed > NVEs. That is right Thomas. > If the question is about the TS having two attachements to the ToR, > wouldn't that be modeled (architecturally) as two distinct > interfaces/ports, in which case each one can connect to its own NVE, > in which case we are good? The questions is about the return traffic coming to the TS. Do you want it = load-split across all the NVEs associated with the TS. The answer is a defi= nite yes, as Joel stated for robustness and to take advantage of all cross-= sectional cheap bandwidth in a data center. Dino >=20 > Thomas _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From xuxiaohu@huawei.com Wed Nov 20 18:26:40 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B361ADF87 for ; Wed, 20 Nov 2013 18:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7MWxmBqMMTP for ; Wed, 20 Nov 2013 18:26:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 992BA1A802B for ; Wed, 20 Nov 2013 18:26:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYD67425; Thu, 21 Nov 2013 02:26:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 02:26:16 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 02:26:27 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 10:26:20 +0800 From: Xuxiaohu To: "nvo3@ietf.org" Thread-Topic: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] Thread-Index: Ac7mYQyuRUS3b71wR4mkX/GRawchNA== Date: Thu, 21 Nov 2013 02:26:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08234DB2@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 02:26:40 -0000 > You can see by now is that my point is that architecturally you shouldn't= say where NVEs are or how they are implemented (in software, hardware or c= ombo software/hardware). > I will argue that if you push an NVE further out there are less of them t= o manage so you get OpEx benefits. I definitely agree with Dino's points. Since this is an architecture draft,= rather than a solution draft, it should be flexible if possible. Best regards, Xiaohu > Dino From kvivek@broadcom.com Wed Nov 20 20:33:05 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14BE1AD79D for ; Wed, 20 Nov 2013 20:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.125 X-Spam-Level: X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLJfa8d56G-H for ; Wed, 20 Nov 2013 20:33:03 -0800 (PST) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEBE1A1F3E for ; Wed, 20 Nov 2013 20:33:03 -0800 (PST) Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 20 Nov 2013 20:31:52 -0800 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 20 Nov 2013 20:32:46 -0800 Received: from SJEXCHMB09.corp.ad.broadcom.com ( [fe80::3da7:665e:cc78:181f]) by SJEXCHCAS05.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Wed, 20 Nov 2013 20:32:46 -0800 From: "Vivek Kumar" To: "Lucy yong" , "Larry Kreeger (kreeger)" , "Erik Nordmark" , "Thomas Narten" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5aJ8FzUGgp4qbUmCVEbHSql+F5otjY2AgACMUAD//394gIABvKQA//+5UQA= Date: Thu, 21 Nov 2013 04:32:46 +0000 Message-ID: <3C086BA39C55B9418AE8FEA3F3EFDEC42AF00EEB@SJEXCHMB09.corp.ad.broadcom.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D452FF555@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF555@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7E93533D1SC9821511-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 04:33:05 -0000 Hi Lucy , See inline below. -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Thursday, November 21, 2013 5:37 AM To: Vivek Kumar; Larry Kreeger (kreeger); Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Sorry to chip in. See inline below. -----Original Message----- From: Vivek Kumar [mailto:kvivek@broadcom.com]=20 Sent: Wednesday, November 20, 2013 12:00 AM To: Larry Kreeger (kreeger); Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Larry, Consider following diagram .=20 TS1->NVE1->L3 network ->NVE2->TS2 . [Lucy] The given example is L3 VN. Both NVE1 and NVE2 are the member of the= L3VN. NVE2 just decapsulates it and forward to TS2. No service needs to pr= ovide at egress. In the case, the VAP interface between TS2-NVE2 is VLAN in= terface, NVE2 learns the TS2 MAC address ahead and inserts the TS2 MAC as t= he dst MAC and its MAC as its src MAC prior sending to TS2. If the VAP is t= he IP interface, NVE2 forward the packet directly to TS2. [Vivek] Thanks for explaining L3 services. How the lookup will happen at NV= E2 for combined L2/L3 services ? Lucy =20 Now , I can have L2/L3 services between TS attached to NVE1 and NVE2 . Lucy= comment clearly explains how NVE1 will detect whether to perform L2 or L3 = services for Tenant frame . My question is when NVE2 decapsulates the packe= t , how it will know which service to provide .=20 Let me know if I am still not clear. Regards, Vivek -----Original Message----- From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Wednesday, November 20, 2013 10:45 AM To: Vivek Kumar; Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Vivek, Can you explain what you mean? We are discussing the service provided to t= he TS. How would it look different to the TS for "L2 serviced or L3 servic= ed when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how=20 >to detect if Tenant Frame has to be L2 serviced or L3 serviced when=20 >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the=20 >broadcast/multicast packet should be sent to another VN is depend on=20 >inter VN policy. It is possible. When the broadcast/multicast packet=20 >deliver to the L3 router too. If the policy allows the=20 >broadcast/multicast to broadcast to another VN, L3 router will forward=20 >the packet to another VN with the same DMAC. If the policy does not=20 >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send=20 >to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3=20 >treatment. > An NVE receiving packets from a TS determines the type of=20 >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a=20 >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the=20 >inter-VN policy, > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 >header (as well > as Ethernet header) . A combined L2/L3 service presents no=20 >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead=20 >the router receives all of them and processes them based on the L3=20 >multicast FIB. > >(For products which implement both L2 and L3 the processing of=20 >multicast depends on whether the input port is L2 or L3, and in some=20 >cases that will result in both bridging the packet out other L2 ports,=20 >and forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC=20 >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of=20 >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP=20 >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no=20 >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text=20 >> to make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to=20 >> have a combined L2/L3 service. Here is proposed text for the=20 >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply =20 >> > describing what we mean by a combined L2/L3 service. That is what=20 >> my >> > text was trying to do. The thinking is if the service definition is=20 >> > clear and simple, supporting it in NVO3 is not a problem. I.e.,=20 >> > it's not really much different to provide a combined service than=20 >> > if you offer an L2 or L3 service. And the service semantics for=20 >> > combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > =20 >> > Whether and how it makes sense to have distributed gateways in a >=20 >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if=20 >> > a distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined >=20 >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the=20 >> same > as taking the two separate L2 and L3 services and combining=20 >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where=20 >> we can easily get > into trouble is if we start defining a combined=20 >> service as has special > cases that have to be dealt with that don't=20 >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From jmh@joelhalpern.com Thu Nov 21 03:00:40 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D1E1ADBCA for ; Thu, 21 Nov 2013 03:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTd9WVfexM9X for ; Thu, 21 Nov 2013 03:00:38 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1318B1AD958 for ; Thu, 21 Nov 2013 03:00:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 941381D25E4; Thu, 21 Nov 2013 03:00:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BBF741C0888; Thu, 21 Nov 2013 03:00:30 -0800 (PST) Message-ID: <528DE7CC.4050307@joelhalpern.com> Date: Thu, 21 Nov 2013 06:00:28 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Narten References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> In-Reply-To: <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 11:00:40 -0000 Doesn't your item 2 assume that what is being delivered is an L3 service? What if the TS is multi-connected to two NVEs, and is getting L2 service to the same tenant bridged space from both of them? Even if the service is layer 3, I would expect the tenant to want all IP addresses to work even if on NVE connection fails. To some degree what you seem to be saying below is that we should always treat multiple TS-NVE connections as if they were separate TS. That seems to be very restrictive on the redundancy models people expect. Yes, as you comment in another note, if we assume the NVE is in the hyperviso then this is a non-problem. But I was under the impression that we were not to make that assumption. Yours, Joel On 11/20/13 2:59 PM, Thomas Narten wrote: > Hi Dino. > >>> I suspect we need to dive a bit deeper into this. i.e., what does >>> "dual attached" mean? > >> A bare-metal server has 2 physical connections to different boxes >> (where a box is a swtich or a router). In some cases, the 2 >> connections are active/active, but mostly active/backup. There is >> some assumption from the server OSes that the upstream boxes are >> layer-2 switches. But it doesn't have to be the case, they can be >> layer-3 routers. > > > I think there are multiple scenarios here to consider, and the details > matter. > > Scenario 1: Bare metal server has 2 separate connections to two > different boxes. How are these two connections presented to the > (bare-metal) TS? > > 1A) two different interfaces are visible to the TS, both with their > own separate IP addresses. This is not an issue for NVO3, since this > is modeled as two interfaces to two separate VNs. (Right?) > > B) TS sees only one interface, the CNA hides the details of two > physical uplinks from TS. Links could be active/active or > active/backup. In this case, the TS has one IP adddress (I presume) > with the CNA hiding the details of multiple uplinks from the TS. > > This is a messier case... Do both uplinks have to connect to the same > NVE? In the standard L2 case, don't both L2 uplinks have to connect to > the "same L2 network"? That only means that both ToRs would need to > support the same VLANs and connect to the same LAN domains. (Right?) > > If above we allow the two uplinks to go to two different NVEs, the > implication is that from an NVO3 perspective, a given TS mapping is > reachable through different NVE addresses. That raises all sorts of > interesting questions. :-) > >>> Do you mean the NVE has two physical connections to the ToR? If so, > >> No, that would be the NVE being able to get ECMP support from the >> underlay. I am talking about the NVE in the TOR, as one example. > > Right, NVE is doing IP and each uplink would be to different L3 dest. > >>> than the question presumably is about allowing/supporting multi-homed >>> NVEs. > >> That is right Thomas. > > Yikes. I guess we need to have that discussion. :) > >>> If the question is about the TS having two attachements to the ToR, >>> wouldn't that be modeled (architecturally) as two distinct >>> interfaces/ports, in which case each one can connect to its own NVE, >>> in which case we are good? > >> The questions is about the return traffic coming to the TS. Do you >> want it load-split across all the NVEs associated with the TS. The >> answer is a definite yes, as Joel stated for robustness and to take >> advantage of all cross-sectional cheap bandwidth in a data center. > > Fundamentally, it means that address mappings (inner to outer) are not > one-to-one, but are one-to-many. > > Is this something we need to support? I agree it has some > benefits. But it also adds some complications... > > Thomas > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > From Balaji.P@freescale.com Thu Nov 21 04:26:38 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E401AE135 for ; Thu, 21 Nov 2013 04:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncp8d9V66Wir for ; Thu, 21 Nov 2013 04:26:35 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id B99761ADEBE for ; Thu, 21 Nov 2013 04:26:34 -0800 (PST) Received: from mail92-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE020.bigfish.com (10.174.4.83) with Microsoft SMTP Server id 14.1.225.22; Thu, 21 Nov 2013 12:26:26 +0000 Received: from mail92-db8 (localhost [127.0.0.1]) by mail92-db8-R.bigfish.com (Postfix) with ESMTP id 26B81640081; Thu, 21 Nov 2013 12:26:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VS-27(zf7Izbb2dI98dI9371I542I1432I1418I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0hbe9i1155h) Received: from mail92-db8 (localhost.localdomain [127.0.0.1]) by mail92-db8 (MessageSwitch) id 1385036784260792_16828; Thu, 21 Nov 2013 12:26:24 +0000 (UTC) Received: from DB8EHSMHS014.bigfish.com (unknown [10.174.8.241]) by mail92-db8.bigfish.com (Postfix) with ESMTP id 2FB19360040; Thu, 21 Nov 2013 12:26:24 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB8EHSMHS014.bigfish.com (10.174.4.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 21 Nov 2013 12:26:23 +0000 Received: from 039-SN2MPN1-023.039d.mgd.msft.net ([169.254.3.171]) by 039-SN1MMR1-002.039d.mgd.msft.net ([10.84.1.15]) with mapi id 14.03.0158.002; Thu, 21 Nov 2013 12:26:22 +0000 From: Balaji P To: Lucy yong , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YZb/F/PxUTviEiLdxEQDV3PCpotS3gAgAAuSoCAAGflwIAAIDcAgAGX81A= Date: Thu, 21 Nov 2013 12:26:22 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452FF384@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452FF384@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.85.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 12:26:38 -0000 Lucy, > IMHO treating L2 and L3 as separate services might be better options > w.r.t NVE. So that based on NVE configuration for L2 and L3 Services will > be applied to the traffic. > [Lucy] The framework has L2 and L3 NVE service type, which apply to many > cases. You can use them to construct various tenant network topologies. > But we also have the case that an NVE may serve the distributed gateway > function. In this case, the VAP may be associated to an L2 VNI on the > NVE, the packet from a TS via the VAP may get L2 or L3 treatment on the > NVE. IMO: it is necessary to differentiate this NVE case from other the > two NVE services. [Balaji] Supporting distributed gateway function definitely makes sense alo= ng with L2 and L3 services. Copied from below text: " A combined L2/L3 service presents no special considerations for NVO3, oth= er than packets received from a tenant must be classified as to what type o= f service they are to be given before they can be processed." [Balaji]when VAP is associated with L2/L3 distributed gateway. Based on the= above text how do we classify this. As we can associate VAP to an L2 VNI o= n the NVE or L3 VNI on NVE. Are we going to have any other VNI type for th= is? Regards, Balaji.P > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, November 20, 2013 5:19 PM > To: P Balaji-B37839; Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Hi Balaji, >=20 > Please see on line. >=20 > -----Original Message----- > From: Balaji P [mailto:Balaji.P@freescale.com] > Sent: Wednesday, November 20, 2013 3:56 AM > To: Lucy yong; Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Lucy, >=20 > As you know L2 and L3 Services for Tenant networks might be based on the > Tenant Network Topology. > [Lucy] agreed. >=20 > Where TS can be configured for multiple L2 Services and L3 Services. > [Lucy] Do you mean the TS as network compliances w/ multiple VAPs and > individual VAPs are associated to a L2 VNI or L3 VNI? If yes, agree too. >=20 > IMHO treating L2 and L3 as separate services might be better options > w.r.t NVE. So that based on NVE configuration for L2 and L3 Services will > be applied to the traffic. > [Lucy] The framework has L2 and L3 NVE service type, which apply to many > cases. You can use them to construct various tenant network topologies. > But we also have the case that an NVE may serve the distributed gateway > function. In this case, the VAP may be associated to an L2 VNI on the > NVE, the packet from a TS via the VAP may get L2 or L3 treatment on the > NVE. IMO: it is necessary to differentiate this NVE case from other the > two NVE services. >=20 > Thanks, > Lucy >=20 > Regards, > Balaji.P >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > > Sent: Wednesday, November 20, 2013 9:12 AM > > To: Erik Nordmark; Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > Erik, > > > > Good point. L2 service provides a broadcast domain. Whether the > > broadcast/multicast packet should be sent to another VN is depend on > > inter VN policy. It is possible. When the broadcast/multicast packet > > deliver to the L3 router too. If the policy allows the > > broadcast/multicast to broadcast to another VN, L3 router will forward > > the packet to another VN with the same DMAC. If the policy does not > > allow, L3 router will drop the packet. > > > > You are right, if dMAC is broadcast/multicast address, it should send > > to > > L3 router for the further process. I change the text to following. > > > > A tenant network may require both L2 and L3 > > services, i.e. the packets from a tenant may get L2 and/or > > L3 treatment. > > An NVE receiving packets from a TS determines the type of > > service to be applied to > > the packet on a per-packet basis and as indicated by the > > destination MAC address on the packet. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE) traffic is given L3 > > semantics with inter-VN policy. When an NVE receives a > > broadcast/multicast packet, > > it should be processed by the L3 router. Depending on the > > inter-VN policy, > > the broadcast/multicast may be allowed or prohibited. > > Otherwise, the packet is given L2 > > semantics. Thus the packet from a tenant must contain IP > > header (as well > > as Ethernet header) . A combined L2/L3 service presents no > > special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > > > Thanks, > > Lucy > > > > > > -----Original Message----- > > From: Erik Nordmark [mailto:nordmark@acm.org] > > Sent: Tuesday, November 19, 2013 6:56 PM > > To: Lucy yong; Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > Lucy, > > > > What would the rules be for multicast packets? > > Such packets are not addressed to a router's MAC address but instead > > the router receives all of them and processes them based on the L3 > > multicast FIB. > > > > (For products which implement both L2 and L3 the processing of > > multicast depends on whether the input port is L2 or L3, and in some > > cases that will result in both bridging the packet out other L2 ports, > > and forwarding the packet out other L3 (virtual) ports.) > > > > Thus AFAICT the multicast rules can't depend on the destination MAC > > address to determine whether L2 or L3 service should be applied. > > > > Erik > > > > On 11/19/13 4:20 PM, Lucy yong wrote: > > > Hi Thomas, > > > > > > How about the following text: > > > > > > A tenant network may require both L2 and L3 > > > services, i.e. the packets from a tenant may get L2 > > > and/or > > > L3 treatment. > > > > > > An NVE receiving packets from a TS determines the type of > > > service to be applied to > > > the packet on a per-packet basis and as indicated by the > > > destination MAC address on the packet. If > > > the MAC address corresponds to that of an L3 router (as > > > determined by the NVE), traffic is given L3 > > > semantics. Otherwise, the packet is given L2 > > > semantics. Thus the packet from a tenant must contain IP > > > header (as well > > > > > > as Ethernet header) . A combined L2/L3 service presents > > > no special > > > considerations for NVO3, other than packets received from > a > > > tenant must be classified as to what type of service they > > > are to be given before they can be processed. > > > > > > Comment: should we use a tenant system (TS) or a tenant in the text > > > to make consistency? > > > > > > Regards, > > > > > > Lucy > > > > > > ---------- Forwarded message ---------- > > > From: *Thomas Narten* > > > > Date: Mon, Nov 18, 2013 at 3:25 PM > > > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > > > To: nvo3@ietf.org > > > > > > > > > There has been some discussion on the list about whether or not to > > > have a combined L2/L3 service. Here is proposed text for the > > > architecture document: > > > > > > > > > A virtual network can also provide a combined L2 and L3 > > > service to tenants. In such cases, a tenant sends and > > > receives both L2 and L3 packets. An NVE recieving packets > > > from a TS determines the type of service to be applied to > > > the packet on a per-packet basis as indicated by the > > > packet's destination MAC address as provided by the TS. > If > > > the MAC address corresponds to that of an L3 router (as > > > determined by the NVE), traffic is given L3 > > > semantics. Otherwise, the packet is given L2 service > > > semantics. A combined L2/L3 service presents no special > > > considerations for NVO3, other than packets received from > a > > > tenant must be classified as to what type of service they > > > are to be given before they can be processed. > > > > > > > > > This text would go at the end of Section 3.1 "VN Service (L2 and > L3)". > > > > > > Make sense? > > > > > > Additional thinking behind this (taken from mail within the DT): > > > > > > > FWIW, I think that there are separate issues here. One is simply > > > > describing what we mean by a combined L2/L3 service. That is what > > > my > > > > text was trying to do. The thinking is if the service definition > > > > is clear and simple, supporting it in NVO3 is not a problem. I.e., > > > > it's not really much different to provide a combined service than > > > > if you offer an L2 or L3 service. And the service semantics for > > > > combined > > > > L2/L3 are easy to understand and explain. That is goodness. :-) > > > > > Whether and how it makes sense to have distributed gateways in a > > > > combined service is a separate matter. What I'd like to be able to > > > do > > > > here (if we need to say anything at all) is be able to say that if > > > > a distributed GW makes sense for L2 service, then having an L2 > > > > distributed GW for the L2 traffic would make sense in the combined > > > > service case too. Ditto for L3 service. > > > > > > > > A key point is that having a combined service is pretty much the > > > same > as taking the two separate L2 and L3 services and combining > > > them into > one implementation. There is nothing really "special" > > > about this that > would complicate the overall architecture. Where > > > we can easily get > into trouble is if we start defining a combined > > > service as has special > cases that have to be dealt with that > > > don't appear when you have only > L2 or only L3 service semantics. > > > > > > Thomas > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Thu Nov 21 07:44:50 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9857C1AE1FF for ; Thu, 21 Nov 2013 07:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfJXWwXMHlAC for ; Thu, 21 Nov 2013 07:44:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE3EE1AE1F3 for ; Thu, 21 Nov 2013 07:44:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAO40581; Thu, 21 Nov 2013 15:44:31 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 15:44:18 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 15:44:30 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 07:44:20 -0800 From: Lucy yong To: Vivek Kumar , "Larry Kreeger (kreeger)" , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAAI/akIAA6g8AgAAzYLA= Date: Thu, 21 Nov 2013 15:44:19 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF794@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <2691CE0099834E4A9C5044EEC662BB9D452FF555@dfweml509-mbx.china.huawei.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AF00EEB@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: <3C086BA39C55B9418AE8FEA3F3EFDEC42AF00EEB@SJEXCHMB09.corp.ad.broadcom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 15:44:50 -0000 Please see [lucy1] Consider following diagram .=20 TS1->NVE1->L3 network ->NVE2->TS2 . [Lucy] The given example is L3 VN. Both NVE1 and NVE2 are the member of the= L3VN. NVE2 just decapsulates it and forward to TS2. No service needs to pr= ovide at egress. In the case, the VAP interface between TS2-NVE2 is VLAN in= terface, NVE2 learns the TS2 MAC address ahead and inserts the TS2 MAC as t= he dst MAC and its MAC as its src MAC prior sending to TS2. If the VAP is t= he IP interface, NVE2 forward the packet directly to TS2. [Vivek] Thanks for explaining L3 services. How the lookup will happen at NV= E2 for combined L2/L3 services ? [Lucy1] No, as I said, your case is L3VN case. Only do IP lookup. In a case= of combined L2/L3 service, it is always the ingress NVE performing the dis= tributed gateway functions, i.e. the packed may be treated as L2 or L3. Whe= n sending the packet to the remote NVE, if using L2VN overlay, the remove N= VE will do Ethernet lookup; if using L3VN overlay, the remove will do IP lo= okup. This is described in the draft-yong-nv03-nve draft. See figure 4 in t= he draft.=20 Lucy =20 Now , I can have L2/L3 services between TS attached to NVE1 and NVE2 . Lucy= comment clearly explains how NVE1 will detect whether to perform L2 or L3 = services for Tenant frame . My question is when NVE2 decapsulates the packe= t , how it will know which service to provide .=20 Let me know if I am still not clear. Regards, Vivek -----Original Message----- From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Wednesday, November 20, 2013 10:45 AM To: Vivek Kumar; Lucy yong; Erik Nordmark; Thomas Narten Cc: nvo3@ietf.org; Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi Vivek, Can you explain what you mean? We are discussing the service provided to t= he TS. How would it look different to the TS for "L2 serviced or L3 servic= ed when decapsulating"? Thanks, Larry On 11/19/13 9:07 PM, "Vivek Kumar" wrote: >Hi Lucy , > One comment regarding your statement . It should also be specified how=20 >to detect if Tenant Frame has to be L2 serviced or L3 serviced when=20 >decapsulating NVO3 overlay header . > >Regards, >Vivek > > >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 20, 2013 9:12 AM >To: Erik Nordmark; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Erik, > >Good point. L2 service provides a broadcast domain. Whether the=20 >broadcast/multicast packet should be sent to another VN is depend on=20 >inter VN policy. It is possible. When the broadcast/multicast packet=20 >deliver to the L3 router too. If the policy allows the=20 >broadcast/multicast to broadcast to another VN, L3 router will forward=20 >the packet to another VN with the same DMAC. If the policy does not=20 >allow, L3 router will drop the packet. > >You are right, if dMAC is broadcast/multicast address, it should send=20 >to >L3 router for the further process. I change the text to following. > > A tenant network may require both L2 and L3 > services, i.e. the packets from a tenant may get L2 and/or L3=20 >treatment. > An NVE receiving packets from a TS determines the type of=20 >service to be applied to > the packet on a per-packet basis and as indicated by the > destination MAC address on the packet. If > the MAC address corresponds to that of an L3 router (as > determined by the NVE) traffic is given L3 > semantics with inter-VN policy. When an NVE receives a=20 >broadcast/multicast packet, > it should be processed by the L3 router. Depending on the=20 >inter-VN policy, > the broadcast/multicast may be allowed or prohibited. >Otherwise, the packet is given L2 > semantics. Thus the packet from a tenant must contain IP=20 >header (as well > as Ethernet header) . A combined L2/L3 service presents no=20 >special > considerations for NVO3, other than packets received from a > tenant must be classified as to what type of service they > are to be given before they can be processed. > > >Thanks, >Lucy >=20 > >-----Original Message----- >From: Erik Nordmark [mailto:nordmark@acm.org] >Sent: Tuesday, November 19, 2013 6:56 PM >To: Lucy yong; Thomas Narten >Cc: nvo3@ietf.org; Linda Dunbar >Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > >Lucy, > >What would the rules be for multicast packets? >Such packets are not addressed to a router's MAC address but instead=20 >the router receives all of them and processes them based on the L3=20 >multicast FIB. > >(For products which implement both L2 and L3 the processing of=20 >multicast depends on whether the input port is L2 or L3, and in some=20 >cases that will result in both bridging the packet out other L2 ports,=20 >and forwarding the packet out other L3 (virtual) ports.) > >Thus AFAICT the multicast rules can't depend on the destination MAC=20 >address to determine whether L2 or L3 service should be applied. > > Erik > >On 11/19/13 4:20 PM, Lucy yong wrote: >> Hi Thomas, >> >> How about the following text: >> >> A tenant network may require both L2 and L3 >> services, i.e. the packets from a tenant may get L2 and/or >> L3 treatment. >> >> An NVE receiving packets from a TS determines the type of=20 >> service to be applied to >> the packet on a per-packet basis and as indicated by the >> destination MAC address on the packet. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 >> semantics. Thus the packet from a tenant must contain IP=20 >> header (as well >> >> as Ethernet header) . A combined L2/L3 service presents no=20 >> special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> Comment: should we use a tenant system (TS) or a tenant in the text=20 >> to make consistency? >> >> Regards, >> >> Lucy >> >> ---------- Forwarded message ---------- >> From: *Thomas Narten* > >> Date: Mon, Nov 18, 2013 at 3:25 PM >> Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service >> To: nvo3@ietf.org >> >> >> There has been some discussion on the list about whether or not to=20 >> have a combined L2/L3 service. Here is proposed text for the=20 >> architecture document: >> >> >> A virtual network can also provide a combined L2 and L3 >> service to tenants. In such cases, a tenant sends and >> receives both L2 and L3 packets. An NVE recieving packets >> from a TS determines the type of service to be applied to >> the packet on a per-packet basis as indicated by the >> packet's destination MAC address as provided by the TS. If >> the MAC address corresponds to that of an L3 router (as >> determined by the NVE), traffic is given L3 >> semantics. Otherwise, the packet is given L2 service >> semantics. A combined L2/L3 service presents no special >> considerations for NVO3, other than packets received from a >> tenant must be classified as to what type of service they >> are to be given before they can be processed. >> >> >> This text would go at the end of Section 3.1 "VN Service (L2 and L3)". >> >> Make sense? >> >> Additional thinking behind this (taken from mail within the DT): >> >> > FWIW, I think that there are separate issues here. One is simply >> > describing what we mean by a combined L2/L3 service. That is what >> my >> > text was trying to do. The thinking is if the service definition is=20 >> > clear and simple, supporting it in NVO3 is not a problem. I.e.,=20 >> > it's not really much different to provide a combined service than=20 >> > if you offer an L2 or L3 service. And the service semantics for=20 >> > combined > >> L2/L3 are easy to understand and explain. That is goodness. :-) > >> > Whether and how it makes sense to have distributed gateways in a > >> combined service is a separate matter. What I'd like to be able to do >> > here (if we need to say anything at all) is be able to say that if=20 >> > a distributed GW makes sense for L2 service, then having an L2 > >> distributed GW for the L2 traffic would make sense in the combined >=20 >> service case too. Ditto for L3 service. >> > >> > A key point is that having a combined service is pretty much the=20 >> same > as taking the two separate L2 and L3 services and combining=20 >> them into > one implementation. There is nothing really "special" >> about this that > would complicate the overall architecture. Where=20 >> we can easily get > into trouble is if we start defining a combined=20 >> service as has special > cases that have to be dealt with that don't=20 >> appear when you have only > L2 or only L3 service semantics. >> >> Thomas >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 >> > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 > > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Thu Nov 21 08:05:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6000B1AE026 for ; Thu, 21 Nov 2013 08:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuBDFMP_SYQw for ; Thu, 21 Nov 2013 08:05:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3CA1AE002 for ; Thu, 21 Nov 2013 08:05:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAO42217; Thu, 21 Nov 2013 16:05:45 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 16:05:31 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 21 Nov 2013 16:05:44 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 08:05:35 -0800 From: Lucy yong To: Balaji P , Erik Nordmark , Thomas Narten Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5YtNXk7jJ5gFTkea8Hv8EekAH5otS3gAgAAuSoCAAGflwIAAIDcAgAGX81CAAD/UAA== Date: Thu, 21 Nov 2013 16:05:34 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452FF7E3@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452FF2EA@dfweml509-mbx.china.huawei.com> <528C0898.4000108@acm.org> <2691CE0099834E4A9C5044EEC662BB9D452FF323@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D452FF384@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:05:56 -0000 Copied from below text: " A combined L2/L3 service presents no special considerations for NVO3, oth= er than packets received from a tenant must be classified as to what type o= f service they are to be given before they can be processed." [Balaji]when VAP is associated with L2/L3 distributed gateway. Based on the= above text how do we classify this. As we can associate VAP to an L2 VNI o= n the NVE or L3 VNI on NVE. Are we going to have any other VNI type for th= is? [Lucy] In combined L2/L3 NVE case, at least one VAP associates to an L2VNI = on the NVE. In other words, the NVE is at least the member of an L2VNI. Please note, the distributed gateway function is an option to be used on NV= E. If a tenant does not allow inter-VN communication or want to use a gatew= ay for inter-VN communication only, no need to use the combined L2/L3 NVE a= t all.=20 Lucy Regards, Balaji.P > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > Sent: Wednesday, November 20, 2013 5:19 PM > To: P Balaji-B37839; Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Hi Balaji, >=20 > Please see on line. >=20 > -----Original Message----- > From: Balaji P [mailto:Balaji.P@freescale.com] > Sent: Wednesday, November 20, 2013 3:56 AM > To: Lucy yong; Erik Nordmark; Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Lucy, >=20 > As you know L2 and L3 Services for Tenant networks might be based on=20 > the Tenant Network Topology. > [Lucy] agreed. >=20 > Where TS can be configured for multiple L2 Services and L3 Services. > [Lucy] Do you mean the TS as network compliances w/ multiple VAPs and=20 > individual VAPs are associated to a L2 VNI or L3 VNI? If yes, agree too. >=20 > IMHO treating L2 and L3 as separate services might be better options=20 > w.r.t NVE. So that based on NVE configuration for L2 and L3 Services=20 > will be applied to the traffic. > [Lucy] The framework has L2 and L3 NVE service type, which apply to=20 > many cases. You can use them to construct various tenant network topologi= es. > But we also have the case that an NVE may serve the distributed=20 > gateway function. In this case, the VAP may be associated to an L2 VNI=20 > on the NVE, the packet from a TS via the VAP may get L2 or L3=20 > treatment on the NVE. IMO: it is necessary to differentiate this NVE=20 > case from other the two NVE services. >=20 > Thanks, > Lucy >=20 > Regards, > Balaji.P >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong > > Sent: Wednesday, November 20, 2013 9:12 AM > > To: Erik Nordmark; Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > Erik, > > > > Good point. L2 service provides a broadcast domain. Whether the=20 > > broadcast/multicast packet should be sent to another VN is depend on=20 > > inter VN policy. It is possible. When the broadcast/multicast packet=20 > > deliver to the L3 router too. If the policy allows the=20 > > broadcast/multicast to broadcast to another VN, L3 router will=20 > > forward the packet to another VN with the same DMAC. If the policy=20 > > does not allow, L3 router will drop the packet. > > > > You are right, if dMAC is broadcast/multicast address, it should=20 > > send to > > L3 router for the further process. I change the text to following. > > > > A tenant network may require both L2 and L3 > > services, i.e. the packets from a tenant may get L2 and/or > > L3 treatment. > > An NVE receiving packets from a TS determines the type of=20 > > service to be applied to > > the packet on a per-packet basis and as indicated by the > > destination MAC address on the packet. If > > the MAC address corresponds to that of an L3 router (as > > determined by the NVE) traffic is given L3 > > semantics with inter-VN policy. When an NVE receives a=20 > > broadcast/multicast packet, > > it should be processed by the L3 router. Depending on the=20 > > inter-VN policy, > > the broadcast/multicast may be allowed or prohibited. > > Otherwise, the packet is given L2 > > semantics. Thus the packet from a tenant must contain IP=20 > > header (as well > > as Ethernet header) . A combined L2/L3 service presents no=20 > > special > > considerations for NVO3, other than packets received from a > > tenant must be classified as to what type of service they > > are to be given before they can be processed. > > > > > > Thanks, > > Lucy > > > > > > -----Original Message----- > > From: Erik Nordmark [mailto:nordmark@acm.org] > > Sent: Tuesday, November 19, 2013 6:56 PM > > To: Lucy yong; Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > Lucy, > > > > What would the rules be for multicast packets? > > Such packets are not addressed to a router's MAC address but instead=20 > > the router receives all of them and processes them based on the L3=20 > > multicast FIB. > > > > (For products which implement both L2 and L3 the processing of=20 > > multicast depends on whether the input port is L2 or L3, and in some=20 > > cases that will result in both bridging the packet out other L2=20 > > ports, and forwarding the packet out other L3 (virtual) ports.) > > > > Thus AFAICT the multicast rules can't depend on the destination MAC=20 > > address to determine whether L2 or L3 service should be applied. > > > > Erik > > > > On 11/19/13 4:20 PM, Lucy yong wrote: > > > Hi Thomas, > > > > > > How about the following text: > > > > > > A tenant network may require both L2 and L3 > > > services, i.e. the packets from a tenant may get L2=20 > > > and/or > > > L3 treatment. > > > > > > An NVE receiving packets from a TS determines the type=20 > > > of service to be applied to > > > the packet on a per-packet basis and as indicated by the > > > destination MAC address on the packet. If > > > the MAC address corresponds to that of an L3 router (as > > > determined by the NVE), traffic is given L3 > > > semantics. Otherwise, the packet is given L2 > > > semantics. Thus the packet from a tenant must contain=20 > > > IP header (as well > > > > > > as Ethernet header) . A combined L2/L3 service presents=20 > > > no special > > > considerations for NVO3, other than packets received=20 > > > from > a > > > tenant must be classified as to what type of service they > > > are to be given before they can be processed. > > > > > > Comment: should we use a tenant system (TS) or a tenant in the=20 > > > text to make consistency? > > > > > > Regards, > > > > > > Lucy > > > > > > ---------- Forwarded message ---------- > > > From: *Thomas Narten* > > > > > > Date: Mon, Nov 18, 2013 at 3:25 PM > > > Subject: [nvo3] Arch: proposed text for Combined L2/L3 Service > > > To: nvo3@ietf.org > > > > > > > > > There has been some discussion on the list about whether or not to=20 > > > have a combined L2/L3 service. Here is proposed text for the=20 > > > architecture document: > > > > > > > > > A virtual network can also provide a combined L2 and L3 > > > service to tenants. In such cases, a tenant sends and > > > receives both L2 and L3 packets. An NVE recieving packets > > > from a TS determines the type of service to be applied to > > > the packet on a per-packet basis as indicated by the > > > packet's destination MAC address as provided by the TS. > If > > > the MAC address corresponds to that of an L3 router (as > > > determined by the NVE), traffic is given L3 > > > semantics. Otherwise, the packet is given L2 service > > > semantics. A combined L2/L3 service presents no special > > > considerations for NVO3, other than packets received=20 > > > from > a > > > tenant must be classified as to what type of service they > > > are to be given before they can be processed. > > > > > > > > > This text would go at the end of Section 3.1 "VN Service (L2 and > L3)". > > > > > > Make sense? > > > > > > Additional thinking behind this (taken from mail within the DT): > > > > > > > FWIW, I think that there are separate issues here. One is=20 > > > simply > > > > describing what we mean by a combined L2/L3 service. That is=20 > > > > what > > > my > > > > text was trying to do. The thinking is if the service definition=20 > > > > is clear and simple, supporting it in NVO3 is not a problem.=20 > > > > I.e., it's not really much different to provide a combined=20 > > > > service than if you offer an L2 or L3 service. And the service=20 > > > > semantics for combined > > > > L2/L3 are easy to understand and explain. That is goodness. :-) =20 > > > > > > > > Whether and how it makes sense to have distributed gateways in a=20 > > > > combined service is a separate matter. What I'd like to be able=20 > > > > to > > > do > > > > here (if we need to say anything at all) is be able to say that=20 > > > > if a distributed GW makes sense for L2 service, then having an=20 > > > > L2 > > > > distributed GW for the L2 traffic would make sense in the combined > > > > service case too. Ditto for L3 service. > > > > > > > > A key point is that having a combined service is pretty much=20 > > > the same > as taking the two separate L2 and L3 services and=20 > > > combining them into > one implementation. There is nothing really "s= pecial" > > > about this that > would complicate the overall architecture.=20 > > > Where we can easily get > into trouble is if we start defining a=20 > > > combined service as has special > cases that have to be dealt=20 > > > with that don't appear when you have only > L2 or only L3 service se= mantics. > > > > > > Thomas > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nordmark@acm.org Fri Nov 22 10:37:44 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28B41AE093 for ; Fri, 22 Nov 2013 10:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSvJnQ3G9mdE for ; Fri, 22 Nov 2013 10:37:44 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 190DA1AE009 for ; Fri, 22 Nov 2013 10:37:43 -0800 (PST) Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAMIbUW0007717 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Nov 2013 10:37:34 -0800 Message-ID: <528FA470.1040301@acm.org> Date: Fri, 22 Nov 2013 10:37:36 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Thomas Narten , Dino Farinacci References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> In-Reply-To: <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;RJojJaVT4xGTMDdv53gOpw== M;MOpBJaVT4xGTMDdv53gOpw== Cc: nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:37:45 -0000 On 11/20/13 2:36 PM, Thomas Narten wrote: > Well, the truth is that NVEs have been assumed to be close to the TS > from day one... And one reason is that if you push the NVE out further > and further away from the TS, it adds complications. We shouldn't do > that unless necessary. If we are saying that architecturally the TS is separate from the NVE with a network in between (to support implementations like off-loading NVE functionality to a TOR), then the question about multihoming will naturally arise. Today there are physical servers which are multihomed (using techniques like active-standby NIC teaming or active-active multi-chassis LAG), and it would seem odd of the NVO3 architecture were to preclude that. BTW: I think the subject like is incorrect. It it the TS that is multihomed (to different NVEs) and the subject talks about multihomed NVEs. Erik From nordmark@acm.org Fri Nov 22 11:12:50 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D11C1AE260 for ; Fri, 22 Nov 2013 11:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ipFTUUgeUs for ; Fri, 22 Nov 2013 11:12:48 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id D60471AE125 for ; Fri, 22 Nov 2013 11:12:48 -0800 (PST) Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAMJCNDk024689 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Nov 2013 11:12:27 -0800 Message-ID: <528FAC9D.6090202@acm.org> Date: Fri, 22 Nov 2013 11:12:29 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Pankaj Garg , Vivek Kumar , "Larry Kreeger (kreeger)" , Lucy yong , Thomas Narten References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Ak1+BKpT4xGYvTBo6sd3kQ== M;agG/BqpT4xGYvTBo6sd3kQ== Cc: "nvo3@ietf.org" , Linda Dunbar Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:12:50 -0000 On 11/20/13 12:07 AM, Pankaj Garg wrote: > Wouldn't the decision to do L2 or L3 service be based on the inner frame fields i.e. destination MAC/IP in the inner frame? Similar to how switches/routers process packets i.e. based on frame's destination MAC and destination IP address (if present)? > > IMHO, Thomas's original text (pasted below) describes this quite well and concisely. > >>> >>> A virtual network can also provide a combined L2 and L3 >>> service to tenants. In such cases, a tenant sends and >>> receives both L2 and L3 packets. An NVE recieving packets >>> from a TS determines the type of service to be applied to >>> the packet on a per-packet basis as indicated by the >>> packet's destination MAC address as provided by the TS. If >>> the MAC address corresponds to that of an L3 router (as >>> determined by the NVE), traffic is given L3 >>> semantics. Otherwise, the packet is given L2 service >>> semantics. A combined L2/L3 service presents no special >>> considerations for NVO3, other than packets received from a >>> tenant must be classified as to what type of service they >>> are to be given before they can be processed. >>> What is missing for me is a higher-level statement whether or not we see an NVE providing combined L2 and L3 service as being architecturally different that the non-overlay case of a bridge+router that provides combined service L2 and L3 today. If we think it is just the same architecturally, then it would make sense to state that. If we think it is different, then I think we need more details that Thomas' text above. FWIW the existing bridge+routers handle multicast conceptually as bridge-route-bridge. A received multicast packet might need to be bridged out other L2 ports in the same bridge domain. Then one copy of packet is passed to the L3 function, which does L3 multicast routing (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF might correspond to a bridge domain i.e., multiple packets might need to be sent out different L2 ports for each oIF. While that is a bit complex, it is a lot better if the NVO3 architecture is the same as existing combined bridge+router boxes. And note that an existing combined bridge+router is architecturally consistent with separate bridges and a router where the bridges only do L2 and the router only does L3. Erik From farinacci@gmail.com Fri Nov 22 11:25:08 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68D01AE072 for ; Fri, 22 Nov 2013 11:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB3NRLn2cd_8 for ; Fri, 22 Nov 2013 11:25:07 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B3E2A1AE03D for ; Fri, 22 Nov 2013 11:25:07 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id ld10so1709965pab.39 for ; Fri, 22 Nov 2013 11:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tMhBtbW1I5a86yp75i3jkorumt0WbWTNSZxfDhP5TKo=; b=y0vV0iue699/AV7UOZayTYJmeYUufzGB/OxGFbrCuNatI4jO/gqrO6bwSxhRFOO3Cy ciqt4IowfY7bEH+ZgfV0aXwJ7O2BJBMw/jRWJPgCwe0ZJJ0/WeedFYsfwF7ypKik3S8C 86XCTnZIdMZ7kIGGfUkpby/RY+nc6rAhaeB94tQAUE6IHA+xJxXhhNrIG8/Nk92LeekH Y9KjHIHNgMynBYICq9xXyZKlT5JIMyOTygKTQTud70AKEnikHdrx/uCRnFa8/5Ui7lga Zu1S6ONUpng7+YrY/GIqMTgVdt29DGj4gnjzIyF4cCj8YUW+NKhaXJUJDKAp5zr1cZ0O DLDg== X-Received: by 10.67.22.67 with SMTP id hq3mr13800344pad.132.1385148300711; Fri, 22 Nov 2013 11:25:00 -0800 (PST) Received: from [192.168.1.8] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ye1sm62184462pab.19.2013.11.22.11.24.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 11:25:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <528FA470.1040301@acm.org> Date: Fri, 22 Nov 2013 11:24:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <408D313D-5978-4652-91FA-11F84EA5FCEC@gmail.com> References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> <528FA470.1040301@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 19:25:09 -0000 > BTW: I think the subject like is incorrect. It it the TS that is = multihomed (to different NVEs) and the subject talks about multihomed = NVEs. Erik, just an FYI, I was referring to both when I brought up the issue. = That is, you need to have generality between the TS and the NVE (a = network, as you stated, either an L2 or L3 network) and a general = network from the NVE out to other NVEs (again a network, mostly likely = only L3, but L2 should just fall out). Dino From nordmark@acm.org Fri Nov 22 13:11:01 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8561AE0D5 for ; Fri, 22 Nov 2013 13:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRCaYbcNjtHx for ; Fri, 22 Nov 2013 13:11:00 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id A39161AE0A4 for ; Fri, 22 Nov 2013 13:11:00 -0800 (PST) Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAMLAooX026155 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 22 Nov 2013 13:10:50 -0800 Message-ID: <528FC860.7040007@acm.org> Date: Fri, 22 Nov 2013 13:10:56 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Dino Farinacci , Erik Nordmark References: <201311152219.rAFMJB1S028844@cichlid.raleigh.ibm.com>, <04a1aa67d001491cbb4c3199a3311b3a@BL2PR05MB082.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C1DB09@dfweml509-mbx.china.huawei.com> <201311201707.rAKH7MgR014153@cichlid.raleigh.ibm.com> <41FE3A30-7698-4FE6-9EDD-51800C5849BD@gmail.com> <201311201731.rAKHVMxK017707@cichlid.raleigh.ibm.com> <740BD593-6F8D-4329-8B44-299F1F45F1EE@gmail.com> <201311201959.rAKJxbXe007752@cichlid.raleigh.ibm.com> <20906E8B-4D64-4718-B481-646E9393778A@gmail.com> <201311202209.rAKM8xXB025807@cichlid.raleigh.ibm.com> <381E57E2-51A1-42A5-B5EA-7C23C27BA08B@gmail.com> <201311202236.rAKMa75H029768@cichlid.raleigh.ibm.com> <528FA470.1040301@acm.org> <408D313D-5978-4652-91FA-11F84EA5FCEC@gmail.com> In-Reply-To: <408D313D-5978-4652-91FA-11F84EA5FCEC@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;DB9RkLpT4xGKxDBo6sd3kQ== M;lleJkLpT4xGKxDBo6sd3kQ== Cc: Thomas Narten , nvo3@ietf.org Subject: Re: [nvo3] Multi-homing of NVEs [was Re: TS conects to VN through one NVE [was Re: No need for NVE-NVE control plane [was Re: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt]] X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 21:11:01 -0000 On 11/22/13 11:24 AM, Dino Farinacci wrote: >> BTW: I think the subject like is incorrect. It it the TS that is multihomed (to different NVEs) and the subject talks about multihomed NVEs. > > Erik, just an FYI, I was referring to both when I brought up the issue. That is, you need to have generality between the TS and the NVE (a network, as you stated, either an L2 or L3 network) and a general network from the NVE out to other NVEs (again a network, mostly likely only L3, but L2 should just fall out). Dino, I was thinking of L3 between NVEs, in which case L3 routing including ECMP takes care of NVEs that are multiply connected. You're correct that if L2 used between NVEs than we need to make sure that the architecture doesn't preclude using existing L2 techniques for multihoming and multipathing. Regards, Erik From david.black@emc.com Fri Nov 22 16:40:38 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECEF1AE2B2 for ; Fri, 22 Nov 2013 16:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxQ_6QDgpYfT for ; Fri, 22 Nov 2013 16:40:35 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0741AE276 for ; Fri, 22 Nov 2013 16:40:35 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAN0ePxH001289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Nov 2013 19:40:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rAN0ePxH001289 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1385167225; bh=EHVv8cL6pfCvtMCbHtu50mKgWOY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=sEIAqmKPddnwRLHoJA5zXrKnZemW9n4vxn2UEDTlkHlFT02WUNioe0Bg6JdoAscpG sh1LHDMpM1SB1Eblh4HhSbkR451ck8x+9kjxD9TWets1+IODtP4khAI87sTVrVBCU2 A8C3SCpxKBKH4U2vTlsv4ltW1r+HsfLGC5jbB904= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rAN0ePxH001289 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 22 Nov 2013 19:40:14 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAN0eDlu019735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 19:40:14 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Fri, 22 Nov 2013 19:40:13 -0500 From: "Black, David" To: Erik Nordmark Date: Fri, 22 Nov 2013 19:40:12 -0500 Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: Ac7nttbVufyRUg/5Sia89YSUPp7vtgALPb7A Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> In-Reply-To: <528FAC9D.6090202@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 00:40:38 -0000 Writing as an individual, not co-author of draft-narten-nvo3-arch: > What is missing for me is a higher-level statement whether or not we see > an NVE providing combined L2 and L3 service as being architecturally > different that the non-overlay case of a bridge+router that provides > combined service L2 and L3 today. >=20 > If we think it is just the same architecturally, then it would make > sense to state that. If we think it is different, then I think we need > more details that Thomas' text above. IMHO, it should be architecturally the same, and we should say so. The quoted text was intended to head in that direction, so an explicit statemen= t seems like a fine idea. I think the touchstone for how L3 service is prov= ided in an L2/L3 service combination should be: "what would happen if there was = no network virtualization?" Thanks, --David > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Friday, November 22, 2013 2:12 PM > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; Thomas > Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > Wouldn't the decision to do L2 or L3 service be based on the inner fram= e > fields i.e. destination MAC/IP in the inner frame? Similar to how > switches/routers process packets i.e. based on frame's destination MAC an= d > destination IP address (if present)? > > > > IMHO, Thomas's original text (pasted below) describes this quite well a= nd > concisely. > > > >>> > >>> A virtual network can also provide a combined L2 and L3 > >>> service to tenants. In such cases, a tenant sends and > >>> receives both L2 and L3 packets. An NVE recieving packets > >>> from a TS determines the type of service to be applied to > >>> the packet on a per-packet basis as indicated by the > >>> packet's destination MAC address as provided by the TS. = If > >>> the MAC address corresponds to that of an L3 router (as > >>> determined by the NVE), traffic is given L3 > >>> semantics. Otherwise, the packet is given L2 service > >>> semantics. A combined L2/L3 service presents no special > >>> considerations for NVO3, other than packets received from= a > >>> tenant must be classified as to what type of service they > >>> are to be given before they can be processed. > >>> >=20 > What is missing for me is a higher-level statement whether or not we see > an NVE providing combined L2 and L3 service as being architecturally > different that the non-overlay case of a bridge+router that provides > combined service L2 and L3 today. >=20 > If we think it is just the same architecturally, then it would make > sense to state that. If we think it is different, then I think we need > more details that Thomas' text above. >=20 > FWIW the existing bridge+routers handle multicast conceptually as > bridge-route-bridge. A received multicast packet might need to be > bridged out other L2 ports in the same bridge domain. Then one copy of > packet is passed to the L3 function, which does L3 multicast routing > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > might correspond to a bridge domain i.e., multiple packets might need to > be sent out different L2 ports for each oIF. >=20 > While that is a bit complex, it is a lot better if the NVO3 architecture > is the same as existing combined bridge+router boxes. >=20 > And note that an existing combined bridge+router is architecturally > consistent with separate bridges and a router where the bridges only do > L2 and the router only does L3. >=20 > Erik >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Sun Nov 24 16:50:20 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A091AE2E9 for ; Sun, 24 Nov 2013 16:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.726 X-Spam-Level: X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_W91IknfjVj for ; Sun, 24 Nov 2013 16:50:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 741A01AE2F8 for ; Sun, 24 Nov 2013 16:50:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYG67326; Mon, 25 Nov 2013 00:50:05 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 00:49:41 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 00:50:02 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Sun, 24 Nov 2013 16:49:59 -0800 From: Lucy yong To: "Black, David" , Erik Nordmark Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwA== Date: Mon, 25 Nov 2013 00:49:59 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 00:50:20 -0000 Here is my 2cent whether combined L2/L3 service is architecturally same or = different from the non-overlay IRB case used today. They are the same in term of the function feature, i.e. a router can provid= e bridging capability for intra VLAN traffic, and bridging capability for i= nter VLANs traffic via routing.=20 But they have differences too. First, an NVE supports this feature in term = of multi-tenancy environment, while a route does it in a single tenancy cas= e (in one address space only). Second, an NVE has both VAP interfaces and o= verlay tunnel interfaces plus internal gw interface. A router only has por= ts or L2 interfaces, which are equivalent to the VAPs on NVE case. (you poi= nt out this) In a multi-tenancy environment, an NVE may be the member for multiple VNs. = Some VN may have independent address spaces, some may share the same addres= s space. An NVE needs to have a VN interconnection policy table which indic= ates which VNs can communicate and which VNs can't. Furthermore the policy = may have finer granularity to a level. For example, between L2VNx and L2VNy= , the policy is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via= a firewall; for multicast traffic, L2VNx<->L2VNy not permit. IMO: the inter-VN policy should be controlled at the VN level, not to the p= articular address (ACL level) or particular application (TCP, HTTP level) i= n the VNs. The latter belongs to the firewall function. =20 Lucy -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David Sent: Friday, November 22, 2013 6:40 PM To: Erik Nordmark Cc: nvo3@ietf.org Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Writing as an individual, not co-author of draft-narten-nvo3-arch: > What is missing for me is a higher-level statement whether or not we=20 > see an NVE providing combined L2 and L3 service as being=20 > architecturally different that the non-overlay case of a bridge+router=20 > that provides combined service L2 and L3 today. >=20 > If we think it is just the same architecturally, then it would make=20 > sense to state that. If we think it is different, then I think we need=20 > more details that Thomas' text above. IMHO, it should be architecturally the same, and we should say so. The quo= ted text was intended to head in that direction, so an explicit statement seems like a fine idea. I think the touchstone for how L3 service is prov= ided in an L2/L3 service combination should be: "what would happen if there was = no network virtualization?" Thanks, --David > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Friday, November 22, 2013 2:12 PM > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > Thomas Narten > Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > Wouldn't the decision to do L2 or L3 service be based on the inner=20 > > frame > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > switches/routers process packets i.e. based on frame's destination MAC=20 > and destination IP address (if present)? > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > well and > concisely. > > > >>> > >>> A virtual network can also provide a combined L2 and L3 > >>> service to tenants. In such cases, a tenant sends and > >>> receives both L2 and L3 packets. An NVE recieving packets > >>> from a TS determines the type of service to be applied to > >>> the packet on a per-packet basis as indicated by the > >>> packet's destination MAC address as provided by the TS. = If > >>> the MAC address corresponds to that of an L3 router (as > >>> determined by the NVE), traffic is given L3 > >>> semantics. Otherwise, the packet is given L2 service > >>> semantics. A combined L2/L3 service presents no special > >>> considerations for NVO3, other than packets received from= a > >>> tenant must be classified as to what type of service they > >>> are to be given before they can be processed. > >>> >=20 > What is missing for me is a higher-level statement whether or not we=20 > see an NVE providing combined L2 and L3 service as being=20 > architecturally different that the non-overlay case of a bridge+router=20 > that provides combined service L2 and L3 today. >=20 > If we think it is just the same architecturally, then it would make=20 > sense to state that. If we think it is different, then I think we need=20 > more details that Thomas' text above. >=20 > FWIW the existing bridge+routers handle multicast conceptually as=20 > bridge-route-bridge. A received multicast packet might need to be=20 > bridged out other L2 ports in the same bridge domain. Then one copy of=20 > packet is passed to the L3 function, which does L3 multicast routing=20 > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF=20 > might correspond to a bridge domain i.e., multiple packets might need=20 > to be sent out different L2 ports for each oIF. >=20 > While that is a bit complex, it is a lot better if the NVO3=20 > architecture is the same as existing combined bridge+router boxes. >=20 > And note that an existing combined bridge+router is architecturally=20 > consistent with separate bridges and a router where the bridges only=20 > do > L2 and the router only does L3. >=20 > Erik >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From Garg.Pankaj@microsoft.com Sun Nov 24 20:14:01 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724F71A1F5B for ; Sun, 24 Nov 2013 20:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RS1yetWteHZ3 for ; Sun, 24 Nov 2013 20:13:59 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) by ietfa.amsl.com (Postfix) with ESMTP id D58DB1A1F54 for ; Sun, 24 Nov 2013 20:13:58 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB125.namprd03.prod.outlook.com (10.242.36.14) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 25 Nov 2013 04:13:57 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.123]) with mapi id 15.00.0820.005; Mon, 25 Nov 2013 04:13:56 +0000 From: Pankaj Garg To: "Black, David" , Erik Nordmark Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a51x/0mA215b0K5pn/ZOIA0I5otk6kAgAAMhYCAACLMkIAD3zuAgABbkQCAA1/AsA== Date: Mon, 25 Nov 2013 04:13:56 +0000 Message-ID: <141d676845f54bf8a18ee27dcd676be0@BY2PR03MB128.namprd03.prod.outlook.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:7020:1020:1588:723b:a28b:1fd2] x-forefront-prvs: 0041D46242 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(51704005)(164054003)(13464003)(2473001)(189002)(199002)(24454002)(479174003)(50986001)(74706001)(49866001)(56816003)(87266001)(76786001)(4396001)(74876001)(77096001)(81816001)(63696002)(80976001)(74316001)(47976001)(47736001)(65816001)(76796001)(47446002)(74502001)(81542001)(81342001)(2656002)(69226001)(53806001)(19580395003)(87936001)(76576001)(15975445006)(77982001)(80022001)(31966008)(59766001)(79102001)(51856001)(56776001)(54356001)(74366001)(81686001)(46102001)(85306002)(76482001)(19580405001)(83322001)(54316002)(74662001)(83072001)(33646001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB125; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:2001:4898:7020:1020:1588:723b:a28b:1fd2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 04:14:01 -0000 +1 for this: ", it should be architecturally the same, and we should say so= ".=20 IMHO, NVE behavior should be same as existing "bridge+router" behavior, wh= ether collocated or not. > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Saturday, November 23, 2013 6:10 AM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. The > quoted text was intended to head in that direction, so an explicit statem= ent > seems like a fine idea. I think the touchstone for how L3 service is pr= ovided > in an L2/L3 service combination should be: "what would happen if there wa= s > no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > switches/routers process packets i.e. based on frame's destination MAC > > and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as > > bridge-route-bridge. A received multicast packet might need to be > > bridged out other L2 ports in the same bridge domain. Then one copy of > > packet is passed to the L3 function, which does L3 multicast routing > > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > > might correspond to a bridge domain i.e., multiple packets might need > > to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally > > consistent with separate bridges and a router where the bridges only > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From jon.hudson@gmail.com Mon Nov 25 00:30:39 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2891AC8F5 for ; Mon, 25 Nov 2013 00:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zp39LLYyial for ; Mon, 25 Nov 2013 00:30:37 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 137E81ACAD7 for ; Mon, 25 Nov 2013 00:30:36 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so6458988ieb.17 for ; Mon, 25 Nov 2013 00:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/5GzljYvFmh3Xo9sLMX76e0P5z2tfQdjeLHihOW1yjk=; b=Jjuxyz/s/C/VBE8cm+U7AA/jemDWPBqM7JavAwLXdGhqkp2sxWdg7QoOkR7CkaE+Uk +g2UNeAoxk2aGzdU6UjjQcKff+RQeeiDFBXsFqDHjksk9cMVimCWemZXq1xXD64EUNkK HXyaHjGSebudbfvoRQKbLjW4YN0HL/ZbYYO8bylvSMJHwxUMMmUP5vLGUMUAqtYMuKbB Gj2k4ILD5Snc+twau+dLbrO1MfR7wrtyt3Goh2Ypsvzaq+omaThlz4LNXC64d7qr3HDU LRuv7u3xd/HJtIq8Q4VogPmveMt6EiGzJL5ZO4rMiQ3ja/tGGZZ7JQ0hq1m7JllPh4+a pMgg== MIME-Version: 1.0 X-Received: by 10.42.40.83 with SMTP id k19mr15342828ice.3.1385368237213; Mon, 25 Nov 2013 00:30:37 -0800 (PST) Received: by 10.50.135.102 with HTTP; Mon, 25 Nov 2013 00:30:37 -0800 (PST) In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> Date: Mon, 25 Nov 2013 00:30:37 -0800 Message-ID: From: Jon Hudson To: "Black, David" Content-Type: multipart/alternative; boundary=90e6ba1efbf4a98e4504ebfc2d71 Cc: Erik Nordmark , "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 08:30:39 -0000 --90e6ba1efbf4a98e4504ebfc2d71 Content-Type: text/plain; charset=ISO-8859-1 +1 agreed >IMHO, it should be architecturally the same, and we should say so. The >quoted text was intended to head in that direction, so an explicit statement >seems like a fine idea..... On Fri, Nov 22, 2013 at 4:40 PM, Black, David wrote: > Writing as an individual, not co-author of draft-narten-nvo3-arch: > > > What is missing for me is a higher-level statement whether or not we see > > an NVE providing combined L2 and L3 service as being architecturally > > different that the non-overlay case of a bridge+router that provides > > combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. > > IMHO, it should be architecturally the same, and we should say so. The > quoted text was intended to head in that direction, so an explicit > statement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there was > no > network virtualization?" > > Thanks, > --David > > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; Thomas > > Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > switches/routers process packets i.e. based on frame's destination MAC > and > > destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite well > and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packets > > >>> from a TS determines the type of service to be applied to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS. > If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received > from a > > >>> tenant must be classified as to what type of service they > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we see > > an NVE providing combined L2 and L3 service as being architecturally > > different that the non-overlay case of a bridge+router that provides > > combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as > > bridge-route-bridge. A received multicast packet might need to be > > bridged out other L2 ports in the same bridge domain. Then one copy of > > packet is passed to the L3 function, which does L3 multicast routing > > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > > might correspond to a bridge domain i.e., multiple packets might need to > > be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3 architecture > > is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally > > consistent with separate bridges and a router where the bridges only do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > -- "Do not lie. And do not do what you hate." --90e6ba1efbf4a98e4504ebfc2d71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+1 agreed

>IMHO, it should be archit= ecturally the same, and we should say so. =A0The
>quoted text= was intended to head in that direction, so an explicit statement>seems like a fine idea.....

<= div class=3D"gmail_extra">

On Fri, Nov 22= , 2013 at 4:40 PM, Black, David <david.black@emc.com> wrot= e:

Writing as an individual, not co-author of d= raft-narten-nvo3-arch:

> What is missing for me is a higher-level statement whether or not we s= ee
> an NVE providing combined L2 and L3 service as being architecturally > different that the non-overlay case of a bridge+router that provides > combined service L2 and L3 today.
>
> If we think it is just the same architecturally, then it would make > sense to state that. If we think it is different, then I think we need=
> more details that Thomas' text above.

IMHO, it should be architecturally the same, and we should say so. = =A0The
quoted text was intended to head in that direction, so an explicit statemen= t
seems like a fine idea. =A0 I think the touchstone for how L3 service is pr= ovided
in an L2/L3 service combination should be: "what would happen if there= was no
network virtualization?"

Thanks,
--David

> -----Original Message-----
> From: nvo3 [mailto:nvo3-bounc= es@ietf.org] On Behalf Of Erik Nordmark
> Sent: Friday, November 22, 2013 2:12 PM
> To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; Thom= as
> Narten
> Cc: nvo3@ietf.org; Linda Dunbar > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Servic= e
>

> On 11/20/13 12:07 AM, Pa= nkaj Garg wrote:
> > Wouldn't the decision to do L2 or L3 service be based on the = inner frame
> fields i.e. destination MAC/IP in the inner frame? Similar to how
> switches/routers process packets i.e. based on frame's destination= MAC and
> destination IP address (if present)?
> >
> > IMHO, Thomas's original text (pasted below) describes this qu= ite well and
> concisely.
> >
> >>> =A0 =A0 =A0 =A0 =A0 <t>
> >>> =A0 =A0 =A0 =A0 =A0 =A0 A virtual network can also provid= e a combined L2 and L3
> >>> =A0 =A0 =A0 =A0 =A0 =A0 service to tenants. In such cases= , a tenant sends and
> >>> =A0 =A0 =A0 =A0 =A0 =A0 receives both L2 and L3 packets. = An NVE recieving packets
> >>> =A0 =A0 =A0 =A0 =A0 =A0 from a TS determines the type of = service to be applied to
> >>> =A0 =A0 =A0 =A0 =A0 =A0 the packet on a per-packet basis = as indicated by the
> >>> =A0 =A0 =A0 =A0 =A0 =A0 packet's destination MAC addr= ess as provided by the TS. =A0If
> >>> =A0 =A0 =A0 =A0 =A0 =A0 the MAC address corresponds to th= at of an L3 router (as
> >>> =A0 =A0 =A0 =A0 =A0 =A0 determined by the NVE), traffic i= s given L3
> >>> =A0 =A0 =A0 =A0 =A0 =A0 semantics. Otherwise, the packet = is given L2 service
> >>> =A0 =A0 =A0 =A0 =A0 =A0 semantics. A combined L2/L3 servi= ce presents no special
> >>> =A0 =A0 =A0 =A0 =A0 =A0 considerations for NVO3, other th= an packets received from a
> >>> =A0 =A0 =A0 =A0 =A0 =A0 tenant must be classified as to w= hat type of service they
> >>> =A0 =A0 =A0 =A0 =A0 =A0 are to be given before they can b= e processed.
> >>> =A0 =A0 =A0 =A0 =A0 </t>
>
> What is missing for me is a higher-level statement whether or not we s= ee
> an NVE providing combined L2 and L3 service as being architecturally > different that the non-overlay case of a bridge+router that provides > combined service L2 and L3 today.
>
> If we think it is just the same architecturally, then it would make > sense to state that. If we think it is different, then I think we need=
> more details that Thomas' text above.
>
> FWIW the existing bridge+routers handle multicast conceptually as
> bridge-route-bridge. A received multicast packet might need to be
> bridged out other L2 ports in the same bridge domain. Then one copy of=
> packet is passed to the L3 function, which does L3 multicast routing > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > might correspond to a bridge domain i.e., multiple packets might need = to
> be sent out different L2 ports for each oIF.
>
> While that is a bit complex, it is a lot better if the NVO3 architectu= re
> is the same as existing combined bridge+router boxes.
>
> And note that an existing combined bridge+router is architecturally > consistent with separate bridges and a router where the bridges only d= o
> L2 and the router only does L3.
>
> =A0 =A0 Erik
>
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
nvo3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/nvo3

--
= "Do not lie. And do not do what you hate."

--90e6ba1efbf4a98e4504ebfc2d71-- From Balaji.P@freescale.com Mon Nov 25 01:54:48 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DAA1ACCFF for ; Mon, 25 Nov 2013 01:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBx1kj8grKqh for ; Mon, 25 Nov 2013 01:54:43 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 889891ACCDF for ; Mon, 25 Nov 2013 01:54:43 -0800 (PST) Received: from mail198-va3-R.bigfish.com (10.7.14.228) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Mon, 25 Nov 2013 09:54:43 +0000 Received: from mail198-va3 (localhost [127.0.0.1]) by mail198-va3-R.bigfish.com (Postfix) with ESMTP id 0ED58320283; Mon, 25 Nov 2013 09:54:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VS-26(zf7Izbb2dI98dI9371I542I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2dh109h2a8h839h8e2h8e3h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h21a6h2216h22d0hbe9i1155h) Received: from mail198-va3 (localhost.localdomain [127.0.0.1]) by mail198-va3 (MessageSwitch) id 1385373259468931_25885; Mon, 25 Nov 2013 09:54:19 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.236]) by mail198-va3.bigfish.com (Postfix) with ESMTP id 631FF10004F; Mon, 25 Nov 2013 09:54:19 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 25 Nov 2013 09:54:19 +0000 Received: from 039-SN2MPN1-023.039d.mgd.msft.net ([169.254.3.171]) by 039-SN1MMR1-001.039d.mgd.msft.net ([10.84.1.13]) with mapi id 14.03.0158.002; Mon, 25 Nov 2013 09:54:18 +0000 From: Balaji P To: "Black, David" , Erik Nordmark Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a51A0PTuz0TjEm0lNl9rxUT3potk6kAgAAMhYCAACOHAIAD3oCAgABbkQCAA7uHgA== Date: Mon, 25 Nov 2013 09:54:17 +0000 Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.232.85.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 09:54:48 -0000 X-List-Received-Date: Mon, 25 Nov 2013 09:54:48 -0000 +1 for David comments. Also if we can add some text w.r.t use cases of handling of L2/L3 service c= ombination will be good. Regards, Balaji.P > IMHO, it should be architecturally the same, and we should say so. The > quoted text was intended to head in that direction, so an explicit > statement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there > was no network virtualization?" > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Saturday, November 23, 2013 6:10 AM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. The > quoted text was intended to head in that direction, so an explicit > statement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there > was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > switches/routers process packets i.e. based on frame's destination MAC > > and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving > packets > > >>> from a TS determines the type of service to be applied > to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS. > If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received > from a > > >>> tenant must be classified as to what type of service > they > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as > > bridge-route-bridge. A received multicast packet might need to be > > bridged out other L2 ports in the same bridge domain. Then one copy of > > packet is passed to the L3 function, which does L3 multicast routing > > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > > might correspond to a bridge domain i.e., multiple packets might need > > to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally > > consistent with separate bridges and a router where the bridges only > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From marc.lasserre@alcatel-lucent.com Mon Nov 25 04:25:11 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DF41AD93D for ; Mon, 25 Nov 2013 04:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpyzuyE_6HvP for ; Mon, 25 Nov 2013 04:25:09 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4911AD937 for ; Mon, 25 Nov 2013 04:25:09 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rAPCP4mi027540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Nov 2013 06:25:06 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAPCP17o010196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 13:25:04 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 25 Nov 2013 13:25:02 +0100 From: "LASSERRE, MARC (MARC)" To: "Black, David" , Erik Nordmark Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a50OeWIdovdeEytAuOAZkURfZotguUAgAAMhoCAACOGAIAD3oGAgABbkACAA/p2UA== Date: Mon, 25 Nov 2013 12:25:01 +0000 Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:25:12 -0000 I agree with David. Marc=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Saturday, November 23, 2013 1:40 AM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined=20 > L2/L3 Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether=20 > or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a=20 > bridge+router=20 > > that provides combined service L2 and L3 today. > >=20 > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I=20 > think we need=20 > > more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should=20 > say so. The quoted text was intended to head in that=20 > direction, so an explicit statement > seems like a fine idea. I think the touchstone for how L3=20 > service is provided > in an L2/L3 service combination should be: "what would happen=20 > if there was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > >=20 > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on=20 > the inner=20 > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > switches/routers process packets i.e. based on frame's=20 > destination MAC=20 > > and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a=20 > combined L2 and L3 > > >>> service to tenants. In such cases, a tenant=20 > sends and > > >>> receives both L2 and L3 packets. An NVE=20 > recieving packets > > >>> from a TS determines the type of service to=20 > be applied to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as=20 > provided by the TS. If > > >>> the MAC address corresponds to that of an=20 > L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service=20 > presents no special > > >>> considerations for NVO3, other than packets=20 > received from a > > >>> tenant must be classified as to what type=20 > of service they > > >>> are to be given before they can be processed. > > >>> > >=20 > > What is missing for me is a higher-level statement whether=20 > or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a=20 > bridge+router=20 > > that provides combined service L2 and L3 today. > >=20 > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I=20 > think we need=20 > > more details that Thomas' text above. > >=20 > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > bridge-route-bridge. A received multicast packet might need to be=20 > > bridged out other L2 ports in the same bridge domain. Then=20 > one copy of=20 > > packet is passed to the L3 function, which does L3=20 > multicast routing=20 > > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF=20 > > might correspond to a bridge domain i.e., multiple packets=20 > might need=20 > > to be sent out different L2 ports for each oIF. > >=20 > > While that is a bit complex, it is a lot better if the NVO3=20 > > architecture is the same as existing combined bridge+router boxes. > >=20 > > And note that an existing combined bridge+router is architecturally=20 > > consistent with separate bridges and a router where the=20 > bridges only=20 > > do > > L2 and the router only does L3. > >=20 > > Erik > >=20 > >=20 > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > = From david.black@emc.com Mon Nov 25 06:36:49 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF61ADDDA for ; Mon, 25 Nov 2013 06:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyiK1LDZqOJN for ; Mon, 25 Nov 2013 06:36:47 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0522B1ADDBF for ; Mon, 25 Nov 2013 06:36:46 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAPEaKTe016447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 09:36:23 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rAPEaKTe016447 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1385390183; bh=AUUKmv9F0unc75ZSTAnQymPHeKo=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lH1YHFFVWWLIO1JWp8FeulIP6LFW8jM3MCGBZMaCKqTVLsj9UsBx+r4sQKLGsjIaP r9e1+IoK6ZG+Y/EyJ9W+9ZRJSzZZo5/C25hOg7IXUf0XSkrmbqwFZQg6mc8ZPEbmfT RlqWNYEiU0Oa7+Qzcx3mDvCNsNeEU0BVDaBLGbPU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rAPEaKTe016447 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 25 Nov 2013 09:36:09 -0500 Received: from mxhub38.corp.emc.com (mxhub38.corp.emc.com [128.222.70.105]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAPEa1Cm007940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 09:36:09 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub38.corp.emc.com ([128.222.70.105]) with mapi; Mon, 25 Nov 2013 09:36:03 -0500 From: "Black, David" To: Lucy yong Date: Mon, 25 Nov 2013 09:36:02 -0500 Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwIADAuVA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 14:36:49 -0000 Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally same o= r > different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can prov= ide > bridging capability for intra VLAN traffic, and bridging capability for i= nter > VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in ter= m of > multi-tenancy environment, while a route does it in a single tenancy case= (in > one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result th= at there can be multiple instances of the router function in the same physical network node in multiple IP address spaces. > Second, an NVE has both VAP interfaces and overlay > tunnel interfaces plus internal gw interface. A router only has ports or= L2 > interfaces, which are equivalent to the VAPs on NVE case. (you point out = this) I think this is over-simplified. A router has interfaces that correspond t= o both overlay tunnel interfaces and its internal gateway (not sure whether this w= as intended to be the gateway facing end systems, or the interface that "defau= lt" is pointed at, if applicable, but the analogy holds for both). For a non-o= verlay environment, these interfaces are not encapsulated, but in general, a route= r has L2/link connectivity to other routers, not just end systems. > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . And a physical routing implementation may provide logically distinct routin= g for multiple VLANs. > Some VN may have independent address spaces, some may share the same addr= ess > space. An NVE needs to have a VN interconnection policy table which indic= ates > which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy, the p= olicy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a firewall= ; for > multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to the > particular address (ACL level) or particular application (TCP, HTTP level= ) in > the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Here is my 2cent whether combined L2/L3 service is architecturally same o= r > different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can prov= ide > bridging capability for intra VLAN traffic, and bridging capability for i= nter > VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in ter= m of > multi-tenancy environment, while a route does it in a single tenancy case= (in > one address space only). Second, an NVE has both VAP interfaces and overl= ay > tunnel interfaces plus internal gw interface. A router only has ports or= L2 > interfaces, which are equivalent to the VAPs on NVE case. (you point out = this) >=20 > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . > Some VN may have independent address spaces, some may share the same addr= ess > space. An NVE needs to have a VN interconnection policy table which indic= ates > which VNs can communicate and which VNs can't. Furthermore the policy may= have > finer granularity to a level. For example, between L2VNx and L2VNy, the p= olicy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a firewall= ; for > multicast traffic, L2VNx<->L2VNy not permit. >=20 > IMO: the inter-VN policy should be controlled at the VN level, not to the > particular address (ACL level) or particular application (TCP, HTTP level= ) in > the VNs. The latter belongs to the firewall function. >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. The q= uoted > text was intended to head in that direction, so an explicit statement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there wa= s no > network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > switches/routers process packets i.e. based on frame's destination MAC > > and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we > > see an NVE providing combined L2 and L3 service as being > > architecturally different that the non-overlay case of a bridge+router > > that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make > > sense to state that. If we think it is different, then I think we need > > more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as > > bridge-route-bridge. A received multicast packet might need to be > > bridged out other L2 ports in the same bridge domain. Then one copy of > > packet is passed to the L3 function, which does L3 multicast routing > > (check iIF, decrement ttl, determine oIFs). Finally, a given L3 oIF > > might correspond to a bridge domain i.e., multiple packets might need > > to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally > > consistent with separate bridges and a router where the bridges only > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From lucy.yong@huawei.com Mon Nov 25 08:11:56 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097A71ADEA7 for ; Mon, 25 Nov 2013 08:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORkqHtTR33-c for ; Mon, 25 Nov 2013 08:11:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 49AC51ADE87 for ; Mon, 25 Nov 2013 08:11:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR64023; Mon, 25 Nov 2013 16:11:50 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 16:11:24 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 16:11:49 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 08:11:44 -0800 From: Lucy yong To: "Black, David" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwIADAuVAgAAUCUA= Date: Mon, 25 Nov 2013 16:11:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:11:56 -0000 Hi David, Please see inline. -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Monday, November 25, 2013 8:36 AM To: Lucy yong Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result th= at there can be multiple instances of the router function in the same physi= cal network node in multiple IP address spaces. [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we t= alk about a router device with bridge capability (i.e. IRB), Isn't such dev= ice operated under one L3 address space, including physical network address= space and source/destination address space? In other words, endpoint and p= hysical network are on the same address space. In traditional DC environmen= t, even VLAN can provide virtual networks, MAC address is uniquely assigned= to physical device, so it is effectively only one MAC address space regard= less whether VLAN is used or not. VLAN provides a virtual private network, = it was not originally intended to provide independent address spaces. =20 > Second, an NVE has both VAP interfaces and overlay tunnel interfaces=20 > plus internal gw interface. A router only has ports or L2 interfaces,=20 > which are equivalent to the VAPs on NVE case. (you point out this) I think this is over-simplified. A router has interfaces that correspond t= o both overlay tunnel interfaces and its internal gateway (not sure whether= this was intended to be the gateway facing end systems, or the interface t= hat "default" is pointed at, if applicable, but the analogy holds for both). For a non-o= verlay environment, these interfaces are not encapsulated, but in general, = a router has L2/link connectivity to other routers, not just end systems. [Lucy] I may over-simplify the router to focus on this case only. My point = is that the router device in this case typically handles one L3 address spa= ce and one MAC address space in the reality.=20 Lucy > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . And a physical routing implementation may provide logically distinct routin= g for multiple VLANs. > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy,=20 > the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). Second, an NVE has both VAP=20 > interfaces and overlay tunnel interfaces plus internal gw interface. =20 > A router only has ports or L2 interfaces, which are equivalent to the=20 > VAPs on NVE case. (you point out this) >=20 > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't.=20 > Furthermore the policy may have finer granularity to a level. For=20 > example, between L2VNx and L2VNy, the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. >=20 > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a=20 > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. =20 > The quoted text was intended to head in that direction, so an explicit st= atement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there=20 > was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner=20 > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > switches/routers process packets i.e. based on frame's destination=20 > > MAC and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a=20 > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > bridge-route-bridge. A received multicast packet might need to be=20 > > bridged out other L2 ports in the same bridge domain. Then one copy=20 > > of packet is passed to the L3 function, which does L3 multicast=20 > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given=20 > > L3 oIF might correspond to a bridge domain i.e., multiple packets=20 > > might need to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3=20 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally=20 > > consistent with separate bridges and a router where the bridges only=20 > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From narten@us.ibm.com Mon Nov 25 08:42:01 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81E41AD947 for ; Mon, 25 Nov 2013 08:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SucwJz9rpxw2 for ; Mon, 25 Nov 2013 08:42:00 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id D77391AD8F7 for ; Mon, 25 Nov 2013 08:41:58 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 25 Nov 2013 11:41:57 -0500 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 25 Nov 2013 11:41:56 -0500 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 1A72AC9004A for ; Mon, 25 Nov 2013 11:41:54 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAPGftoh5177738 for ; Mon, 25 Nov 2013 16:41:55 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAPGftPo023365 for ; Mon, 25 Nov 2013 11:41:55 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-158-76.mts.ibm.com [9.65.158.76]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAPGfqDU023141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 11:41:54 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAPGfqYV031311; Mon, 25 Nov 2013 11:41:52 -0500 Message-Id: <201311251641.rAPGfqYV031311@cichlid.raleigh.ibm.com> To: "Bocci, Matthew (Matthew)" In-reply-to: References: Comments: In-reply-to "Bocci, Matthew (Matthew)" message dated "Wed, 13 Nov 2013 13:57:45 +0000." Date: Mon, 25 Nov 2013 11:41:52 -0500 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112516-7182-0000-0000-0000093377FB Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 16:42:02 -0000 Support as co-author and am not not aware of IPR that applies to this draft. Thomas From david.black@emc.com Mon Nov 25 09:56:17 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60751ADFAC for ; Mon, 25 Nov 2013 09:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO5GnbQEh7tt for ; Mon, 25 Nov 2013 09:56:14 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53E1ACB4E for ; Mon, 25 Nov 2013 09:56:13 -0800 (PST) Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAPHu2QI023076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Nov 2013 12:56:04 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rAPHu2QI023076 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1385402164; bh=43ZcJgpJON5DhB7E3JfhCloNe4A=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=w4VvgjhIUb4dtI35pjthHu2lp0TCRTAluZQCh+oaW8WFyKhIg4/P/F4E2YPhUdApy uyl4JnMWGIF3+Gc017RUKS53T6d5mJAbHkdNm2CbsFPT11nMRqddDHDHtuox/NgsMz de1NnouW4KhaZkkJDhSDq8q9Us/LYiNDZQuvrGDQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com rAPHu2QI023076 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Mon, 25 Nov 2013 12:55:47 -0500 Received: from mxhub40.corp.emc.com (mxhub40.corp.emc.com [128.222.70.107]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rAPHtkAK002976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 12:55:47 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub40.corp.emc.com ([128.222.70.107]) with mapi; Mon, 25 Nov 2013 12:55:46 -0500 From: "Black, David" To: Lucy yong Date: Mon, 25 Nov 2013 12:55:45 -0500 Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwIADAuVAgAAUCUCAABixwA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712026ADFA92C@MX15A.corp.emc.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 17:56:18 -0000 Lucy, > > But they have differences too. First, an NVE supports this feature in > > term of multi-tenancy environment, while a route does it in a single > > tenancy case (in one address space only). >=20 > I firmly disagree. VLANs can be used for multi-tenancy, with the result = that > there can be multiple instances of the router function in the same physic= al > network node in multiple IP address spaces. -- > I firmly disagree. VLANs can be used for multi-tenancy, with the result = that > there can be multiple instances of the router function in the same physic= al > network node in multiple IP address spaces. -- > [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we= talk > about a router device with bridge capability (i.e. IRB), Isn't such devic= e > operated under one L3 address space, including physical network address s= pace > and source/destination address space? No, we aren't talking about a single "router device" - when I wrote "multip= le instances of the router function", I meant a device that can operate multip= le instances of the router function that can be in separate source/destination address spaces (e.g., I expect to see multiple independent instances of the 10.0.0.0/8 address block in a multi-tenant data center). In addition, an NVE has to deal with the underlay address space. I view that underlay address space as secondary - the routing function make= s an IP routing decision about where to forward a packet. That decision is a= bout what "logical port" to emit the packet on ("logical interface" is a better term in this context) - the encapsulation and the underlay address are func= tional consequences of that forwarding decision. > [Lucy] I may over-simplify the router to focus on this case only. My poin= t is > that the router device in this case typically handles one L3 address spac= e and > one MAC address space in the reality. See above on "multiple instances" of the "router". Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, November 25, 2013 11:12 AM > To: Black, David > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Hi David, >=20 > Please see inline. >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Monday, November 25, 2013 8:36 AM > To: Lucy yong > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service >=20 > Lucy, >=20 > > Here is my 2cent whether combined L2/L3 service is architecturally > > same or different from the non-overlay IRB case used today. > > > > They are the same in term of the function feature, i.e. a router can > > provide bridging capability for intra VLAN traffic, and bridging > > capability for inter VLANs traffic via routing. > > > > But they have differences too. First, an NVE supports this feature in > > term of multi-tenancy environment, while a route does it in a single > > tenancy case (in one address space only). >=20 > I firmly disagree. VLANs can be used for multi-tenancy, with the result = that > there can be multiple instances of the router function in the same physic= al > network node in multiple IP address spaces. > [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we= talk > about a router device with bridge capability (i.e. IRB), Isn't such devic= e > operated under one L3 address space, including physical network address s= pace > and source/destination address space? In other words, endpoint and physic= al > network are on the same address space. In traditional DC environment, eve= n > VLAN can provide virtual networks, MAC address is uniquely assigned to > physical device, so it is effectively only one MAC address space regardle= ss > whether VLAN is used or not. VLAN provides a virtual private network, it = was > not originally intended to provide independent address spaces. >=20 > > Second, an NVE has both VAP interfaces and overlay tunnel interfaces > > plus internal gw interface. A router only has ports or L2 interfaces, > > which are equivalent to the VAPs on NVE case. (you point out this) >=20 > I think this is over-simplified. A router has interfaces that correspond= to > both overlay tunnel interfaces and its internal gateway (not sure whether= this > was intended to be the gateway facing end systems, or the interface that > "default" > is pointed at, if applicable, but the analogy holds for both). For a non= - > overlay environment, these interfaces are not encapsulated, but in genera= l, a > router has L2/link connectivity to other routers, not just end systems. > [Lucy] I may over-simplify the router to focus on this case only. My poin= t is > that the router device in this case typically handles one L3 address spac= e and > one MAC address space in the reality. >=20 > Lucy >=20 > > In a multi-tenancy environment, an NVE may be the member for multiple V= Ns. >=20 > And a physical routing implementation may provide logically distinct rout= ing > for multiple VLANs. >=20 > > Some VN may have independent address spaces, some may share the same > > address space. An NVE needs to have a VN interconnection policy table > > which indicates which VNs can communicate and which VNs can't >=20 > Likewise for routing and VLANs. >=20 > > Furthermore the policy may have > > finer granularity to a level. For example, between L2VNx and L2VNy, > > the policy > > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a > > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > > > IMO: the inter-VN policy should be controlled at the VN level, not to > > the particular address (ACL level) or particular application (TCP, > > HTTP level) in the VNs. The latter belongs to the firewall function. >=20 > And also likewise for routing and VLANs. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Sunday, November 24, 2013 7:50 PM > > To: Black, David; Erik Nordmark > > Cc: nvo3@ietf.org > > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > Here is my 2cent whether combined L2/L3 service is architecturally > > same or different from the non-overlay IRB case used today. > > > > They are the same in term of the function feature, i.e. a router can > > provide bridging capability for intra VLAN traffic, and bridging > > capability for inter VLANs traffic via routing. > > > > But they have differences too. First, an NVE supports this feature in > > term of multi-tenancy environment, while a route does it in a single > > tenancy case (in one address space only). Second, an NVE has both VAP > > interfaces and overlay tunnel interfaces plus internal gw interface. > > A router only has ports or L2 interfaces, which are equivalent to the > > VAPs on NVE case. (you point out this) > > > > In a multi-tenancy environment, an NVE may be the member for multiple V= Ns. > > Some VN may have independent address spaces, some may share the same > > address space. An NVE needs to have a VN interconnection policy table > > which indicates which VNs can communicate and which VNs can't. > > Furthermore the policy may have finer granularity to a level. For > > example, between L2VNx and L2VNy, the policy > > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a > > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > > > IMO: the inter-VN policy should be controlled at the VN level, not to > > the particular address (ACL level) or particular application (TCP, > > HTTP level) in the VNs. The latter belongs to the firewall function. > > > > Lucy > > > > > > > > > > > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > > Sent: Friday, November 22, 2013 6:40 PM > > To: Erik Nordmark > > Cc: nvo3@ietf.org > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > Service > > > > Writing as an individual, not co-author of draft-narten-nvo3-arch: > > > > > What is missing for me is a higher-level statement whether or not we > > > see an NVE providing combined L2 and L3 service as being > > > architecturally different that the non-overlay case of a > > > bridge+router that provides combined service L2 and L3 today. > > > > > > If we think it is just the same architecturally, then it would make > > > sense to state that. If we think it is different, then I think we > > > need more details that Thomas' text above. > > > > IMHO, it should be architecturally the same, and we should say so. > > The quoted text was intended to head in that direction, so an explicit > statement > > seems like a fine idea. I think the touchstone for how L3 service is > > provided > > in an L2/L3 service combination should be: "what would happen if there > > was no network virtualization?" > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > > Sent: Friday, November 22, 2013 2:12 PM > > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong; > > > Thomas Narten > > > Cc: nvo3@ietf.org; Linda Dunbar > > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 > > > Service > > > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > > Wouldn't the decision to do L2 or L3 service be based on the inner > > > > frame > > > fields i.e. destination MAC/IP in the inner frame? Similar to how > > > switches/routers process packets i.e. based on frame's destination > > > MAC and destination IP address (if present)? > > > > > > > > IMHO, Thomas's original text (pasted below) describes this quite > > > > well and > > > concisely. > > > > > > > >>> > > > >>> A virtual network can also provide a combined L2 and = L3 > > > >>> service to tenants. In such cases, a tenant sends and > > > >>> receives both L2 and L3 packets. An NVE recieving pac= kets > > > >>> from a TS determines the type of service to be applie= d to > > > >>> the packet on a per-packet basis as indicated by the > > > >>> packet's destination MAC address as provided by the T= S. > If > > > >>> the MAC address corresponds to that of an L3 router (= as > > > >>> determined by the NVE), traffic is given L3 > > > >>> semantics. Otherwise, the packet is given L2 service > > > >>> semantics. A combined L2/L3 service presents no speci= al > > > >>> considerations for NVO3, other than packets received = from > a > > > >>> tenant must be classified as to what type of service = they > > > >>> are to be given before they can be processed. > > > >>> > > > > > > What is missing for me is a higher-level statement whether or not we > > > see an NVE providing combined L2 and L3 service as being > > > architecturally different that the non-overlay case of a > > > bridge+router that provides combined service L2 and L3 today. > > > > > > If we think it is just the same architecturally, then it would make > > > sense to state that. If we think it is different, then I think we > > > need more details that Thomas' text above. > > > > > > FWIW the existing bridge+routers handle multicast conceptually as > > > bridge-route-bridge. A received multicast packet might need to be > > > bridged out other L2 ports in the same bridge domain. Then one copy > > > of packet is passed to the L3 function, which does L3 multicast > > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given > > > L3 oIF might correspond to a bridge domain i.e., multiple packets > > > might need to be sent out different L2 ports for each oIF. > > > > > > While that is a bit complex, it is a lot better if the NVO3 > > > architecture is the same as existing combined bridge+router boxes. > > > > > > And note that an existing combined bridge+router is architecturally > > > consistent with separate bridges and a router where the bridges only > > > do > > > L2 and the router only does L3. > > > > > > Erik > > > > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 From lucy.yong@huawei.com Mon Nov 25 10:16:37 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5F91ADF90 for ; Mon, 25 Nov 2013 10:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So9QK8WOUKUM for ; Mon, 25 Nov 2013 10:16:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4942B1ADF94 for ; Mon, 25 Nov 2013 10:16:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAR72310; Mon, 25 Nov 2013 18:16:26 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 18:15:59 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 18:16:22 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 10:16:17 -0800 From: Lucy yong To: "Black, David" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwIADAuVAgAAUCUCAABixwIAAEPGQ Date: Mon, 25 Nov 2013 18:16:16 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45301DB3@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA92C@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712026ADFA92C@MX15A.corp.emc.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:16:37 -0000 David, I know that NVO3 architecture targets multi-tenant environment from day one= .=20 Eric initially question is if combined L3/L2 service in NVO3 is the archite= cturally same as the today's router with bridging capability, i.e. IRB used= in a physical network today. This is the router I referenced in my mail. I think that my view is the same as yours. Thanks, Lucy -----Original Message----- From: Black, David [mailto:david.black@emc.com]=20 Sent: Monday, November 25, 2013 11:56 AM To: Lucy yong Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > > But they have differences too. First, an NVE supports this feature=20 > > in term of multi-tenancy environment, while a route does it in a=20 > > single tenancy case (in one address space only). >=20 > I firmly disagree. VLANs can be used for multi-tenancy, with the=20 > result that there can be multiple instances of the router function in=20 > the same physical network node in multiple IP address spaces. -- > I firmly disagree. VLANs can be used for multi-tenancy, with the=20 > result that there can be multiple instances of the router function in=20 > the same physical network node in multiple IP address spaces. -- > [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context,=20 > we talk about a router device with bridge capability (i.e. IRB), Isn't=20 > such device operated under one L3 address space, including physical=20 > network address space and source/destination address space? No, we aren't talking about a single "router device" - when I wrote "multip= le instances of the router function", I meant a device that can operate mul= tiple instances of the router function that can be in separate source/desti= nation address spaces (e.g., I expect to see multiple independent instances= of the 10.0.0.0/8 address block in a multi-tenant data center). In addition, an N= VE has to deal with the underlay address space. I view that underlay address space as secondary - the routing function make= s an IP routing decision about where to forward a packet. That decision is= about what "logical port" to emit the packet on ("logical interface" is a = better term in this context) - the encapsulation and the underlay address a= re functional consequences of that forwarding decision. > [Lucy] I may over-simplify the router to focus on this case only. My=20 > point is that the router device in this case typically handles one L3=20 > address space and one MAC address space in the reality. See above on "multiple instances" of the "router". Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Monday, November 25, 2013 11:12 AM > To: Black, David > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Hi David, >=20 > Please see inline. >=20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Monday, November 25, 2013 8:36 AM > To: Lucy yong > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Lucy, >=20 > > Here is my 2cent whether combined L2/L3 service is architecturally=20 > > same or different from the non-overlay IRB case used today. > > > > They are the same in term of the function feature, i.e. a router can=20 > > provide bridging capability for intra VLAN traffic, and bridging=20 > > capability for inter VLANs traffic via routing. > > > > But they have differences too. First, an NVE supports this feature=20 > > in term of multi-tenancy environment, while a route does it in a=20 > > single tenancy case (in one address space only). >=20 > I firmly disagree. VLANs can be used for multi-tenancy, with the=20 > result that there can be multiple instances of the router function in=20 > the same physical network node in multiple IP address spaces. > [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context,=20 > we talk about a router device with bridge capability (i.e. IRB), Isn't=20 > such device operated under one L3 address space, including physical=20 > network address space and source/destination address space? In other=20 > words, endpoint and physical network are on the same address space. In=20 > traditional DC environment, even VLAN can provide virtual networks,=20 > MAC address is uniquely assigned to physical device, so it is=20 > effectively only one MAC address space regardless whether VLAN is used=20 > or not. VLAN provides a virtual private network, it was not originally in= tended to provide independent address spaces. >=20 > > Second, an NVE has both VAP interfaces and overlay tunnel interfaces=20 > > plus internal gw interface. A router only has ports or L2=20 > > interfaces, which are equivalent to the VAPs on NVE case. (you point=20 > > out this) >=20 > I think this is over-simplified. A router has interfaces that=20 > correspond to both overlay tunnel interfaces and its internal gateway=20 > (not sure whether this was intended to be the gateway facing end=20 > systems, or the interface that "default" > is pointed at, if applicable, but the analogy holds for both). For a=20 > non- overlay environment, these interfaces are not encapsulated, but=20 > in general, a router has L2/link connectivity to other routers, not just = end systems. > [Lucy] I may over-simplify the router to focus on this case only. My=20 > point is that the router device in this case typically handles one L3=20 > address space and one MAC address space in the reality. >=20 > Lucy >=20 > > In a multi-tenancy environment, an NVE may be the member for multiple V= Ns. >=20 > And a physical routing implementation may provide logically distinct=20 > routing for multiple VLANs. >=20 > > Some VN may have independent address spaces, some may share the same=20 > > address space. An NVE needs to have a VN interconnection policy=20 > > table which indicates which VNs can communicate and which VNs can't >=20 > Likewise for routing and VLANs. >=20 > > Furthermore the policy may have > > finer granularity to a level. For example, between L2VNx and L2VNy,=20 > > the policy > > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > > > IMO: the inter-VN policy should be controlled at the VN level, not=20 > > to the particular address (ACL level) or particular application=20 > > (TCP, HTTP level) in the VNs. The latter belongs to the firewall functi= on. >=20 > And also likewise for routing and VLANs. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Sunday, November 24, 2013 7:50 PM > > To: Black, David; Erik Nordmark > > Cc: nvo3@ietf.org > > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > Here is my 2cent whether combined L2/L3 service is architecturally=20 > > same or different from the non-overlay IRB case used today. > > > > They are the same in term of the function feature, i.e. a router can=20 > > provide bridging capability for intra VLAN traffic, and bridging=20 > > capability for inter VLANs traffic via routing. > > > > But they have differences too. First, an NVE supports this feature=20 > > in term of multi-tenancy environment, while a route does it in a=20 > > single tenancy case (in one address space only). Second, an NVE has=20 > > both VAP interfaces and overlay tunnel interfaces plus internal gw inte= rface. > > A router only has ports or L2 interfaces, which are equivalent to=20 > > the VAPs on NVE case. (you point out this) > > > > In a multi-tenancy environment, an NVE may be the member for multiple V= Ns. > > Some VN may have independent address spaces, some may share the same=20 > > address space. An NVE needs to have a VN interconnection policy=20 > > table which indicates which VNs can communicate and which VNs can't. > > Furthermore the policy may have finer granularity to a level. For=20 > > example, between L2VNx and L2VNy, the policy > > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > > > IMO: the inter-VN policy should be controlled at the VN level, not=20 > > to the particular address (ACL level) or particular application=20 > > (TCP, HTTP level) in the VNs. The latter belongs to the firewall functi= on. > > > > Lucy > > > > > > > > > > > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > > Sent: Friday, November 22, 2013 6:40 PM > > To: Erik Nordmark > > Cc: nvo3@ietf.org > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > Writing as an individual, not co-author of draft-narten-nvo3-arch: > > > > > What is missing for me is a higher-level statement whether or not=20 > > > we see an NVE providing combined L2 and L3 service as being=20 > > > architecturally different that the non-overlay case of a > > > bridge+router that provides combined service L2 and L3 today. > > > > > > If we think it is just the same architecturally, then it would=20 > > > make sense to state that. If we think it is different, then I=20 > > > think we need more details that Thomas' text above. > > > > IMHO, it should be architecturally the same, and we should say so. > > The quoted text was intended to head in that direction, so an=20 > > explicit > statement > > seems like a fine idea. I think the touchstone for how L3 service is > > provided > > in an L2/L3 service combination should be: "what would happen if=20 > > there was no network virtualization?" > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik=20 > > > Nordmark > > > Sent: Friday, November 22, 2013 2:12 PM > > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > > Thomas Narten > > > Cc: nvo3@ietf.org; Linda Dunbar > > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > > Service > > > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > > Wouldn't the decision to do L2 or L3 service be based on the=20 > > > > inner frame > > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > > switches/routers process packets i.e. based on frame's destination=20 > > > MAC and destination IP address (if present)? > > > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > > well and > > > concisely. > > > > > > > >>> > > > >>> A virtual network can also provide a combined L2 and = L3 > > > >>> service to tenants. In such cases, a tenant sends and > > > >>> receives both L2 and L3 packets. An NVE recieving pac= kets > > > >>> from a TS determines the type of service to be applie= d to > > > >>> the packet on a per-packet basis as indicated by the > > > >>> packet's destination MAC address as provided by the T= S. > If > > > >>> the MAC address corresponds to that of an L3 router (= as > > > >>> determined by the NVE), traffic is given L3 > > > >>> semantics. Otherwise, the packet is given L2 service > > > >>> semantics. A combined L2/L3 service presents no speci= al > > > >>> considerations for NVO3, other than packets=20 > > > >>> received from > a > > > >>> tenant must be classified as to what type of service = they > > > >>> are to be given before they can be processed. > > > >>> > > > > > > What is missing for me is a higher-level statement whether or not=20 > > > we see an NVE providing combined L2 and L3 service as being=20 > > > architecturally different that the non-overlay case of a > > > bridge+router that provides combined service L2 and L3 today. > > > > > > If we think it is just the same architecturally, then it would=20 > > > make sense to state that. If we think it is different, then I=20 > > > think we need more details that Thomas' text above. > > > > > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > > bridge-route-bridge. A received multicast packet might need to be=20 > > > bridged out other L2 ports in the same bridge domain. Then one=20 > > > copy of packet is passed to the L3 function, which does L3=20 > > > multicast routing (check iIF, decrement ttl, determine oIFs).=20 > > > Finally, a given > > > L3 oIF might correspond to a bridge domain i.e., multiple packets=20 > > > might need to be sent out different L2 ports for each oIF. > > > > > > While that is a bit complex, it is a lot better if the NVO3=20 > > > architecture is the same as existing combined bridge+router boxes. > > > > > > And note that an existing combined bridge+router is=20 > > > architecturally consistent with separate bridges and a router=20 > > > where the bridges only do > > > L2 and the router only does L3. > > > > > > Erik > > > > > > > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 From david.i.allan@ericsson.com Mon Nov 25 16:29:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B352B1AE0E4 for ; Mon, 25 Nov 2013 16:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-eUfjL3_oWH for ; Mon, 25 Nov 2013 16:29:49 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0FD1AE07D for ; Mon, 25 Nov 2013 16:29:49 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-b8-5293eb7a82e9 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id D3.B6.04556.A7BE3925; Tue, 26 Nov 2013 01:29:47 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Mon, 25 Nov 2013 19:29:46 -0500 From: David Allan I To: Lucy yong , "Black, David" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a5z2g7UpXJ/FEupqKV7wmC9AZot53oAgAAMhoCAACOGAIAD3oGAgABbkACAAydmgIAA5ssAgAAavICAADTD8A== Date: Tue, 26 Nov 2013 00:29:46 +0000 Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXSPt27168lBBh0XhS22Hl7LbrHx1yI2 i6fzJR2YPY4cmc3i0XLkLavHkiU/mQKYo7hsUlJzMstSi/TtErgynp6fxFYwNaJi/rvj7A2M r127GDk5JARMJL5tPsAOYYtJXLi3nq2LkYtDSOAIo8T/Y7MYQRJCAssZJSb+lQWx2QQMJPb8 /wIWFxHwkrjV0MDSxcjBwSygLNHcaQ0SFhZwl7h3bRsrRImHROfOZ1DlWRIP5q9hBrFZBFQl ri6eyAJi8wr4Stw8cpsJYtVZFonLS9NAbE6BMIkVm5vZQGxGoNu+n1oDVsMsIC5x68l8Joib BSSW7DnPDGGLSrx8/I8VwlaW+D7nEQtEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaxWUjG zkLSMgtJyywkLQsYWVYxcpQWp5blphsZbmIERs0xCTbHHYwLPlkeYpTmYFES5/3y1jlISCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+OB2cVms+9PTYy0fOwmXTrjb4qJ92ynL45PWs54PFs6 bduHOY5TJid4T5IvS3Q4kvvfbdL/hlXdV7gdHTS516f3PK6V2nJnfaDFht98mu/aDN7O0Hwv f0PUPEu33l2qSUHhvdlGaQeuDQUC+nst4pzzFyrsz/fQTThesnr59NRD6+KW6fnO2qjEUpyR aKjFXFScCAC8+KIhaAIAAA== Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 00:29:51 -0000 Lucy, Any non-interconnect of tenant networks in a common routing implementation = will require lots of ACLs which can be gotten wrong, and would not permit r= euse of private addressing by multiple tenants sharing a router FDB....and = could be messed up by duplicate MAC addresses. IMO it is a bad idea, it places a lot of constraints on virtualization (e.g= . it can only work if..and if... and if...etc.) so it becomes somewhat half= baked.=20 If a tenant requires multiple interconnected subnets they need their own VR= F/VR implementation, own ARP cache etc to obviate the potential problems. W= hy would we WANT to allow otherwise? My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Monday, November 25, 2013 8:12 AM To: Black, David Cc: nvo3@ietf.org Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi David, Please see inline. -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Monday, November 25, 2013 8:36 AM To: Lucy yong Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result th= at there can be multiple instances of the router function in the same physi= cal network node in multiple IP address spaces. [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we t= alk about a router device with bridge capability (i.e. IRB), Isn't such dev= ice operated under one L3 address space, including physical network address= space and source/destination address space? In other words, endpoint and p= hysical network are on the same address space. In traditional DC environmen= t, even VLAN can provide virtual networks, MAC address is uniquely assigned= to physical device, so it is effectively only one MAC address space regard= less whether VLAN is used or not. VLAN provides a virtual private network, = it was not originally intended to provide independent address spaces. =20 > Second, an NVE has both VAP interfaces and overlay tunnel interfaces=20 > plus internal gw interface. A router only has ports or L2 interfaces,=20 > which are equivalent to the VAPs on NVE case. (you point out this) I think this is over-simplified. A router has interfaces that correspond t= o both overlay tunnel interfaces and its internal gateway (not sure whether= this was intended to be the gateway facing end systems, or the interface t= hat "default" is pointed at, if applicable, but the analogy holds for both). For a non-o= verlay environment, these interfaces are not encapsulated, but in general, = a router has L2/link connectivity to other routers, not just end systems. [Lucy] I may over-simplify the router to focus on this case only. My point = is that the router device in this case typically handles one L3 address spa= ce and one MAC address space in the reality.=20 Lucy > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . And a physical routing implementation may provide logically distinct routin= g for multiple VLANs. > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy,=20 > the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). Second, an NVE has both VAP=20 > interfaces and overlay tunnel interfaces plus internal gw interface. > A router only has ports or L2 interfaces, which are equivalent to the=20 > VAPs on NVE case. (you point out this) >=20 > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't. > Furthermore the policy may have finer granularity to a level. For=20 > example, between L2VNx and L2VNy, the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. >=20 > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. =20 > The quoted text was intended to head in that direction, so an explicit st= atement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there=20 > was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner=20 > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > switches/routers process packets i.e. based on frame's destination=20 > > MAC and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > bridge-route-bridge. A received multicast packet might need to be=20 > > bridged out other L2 ports in the same bridge domain. Then one copy=20 > > of packet is passed to the L3 function, which does L3 multicast=20 > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given > > L3 oIF might correspond to a bridge domain i.e., multiple packets=20 > > might need to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3=20 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally=20 > > consistent with separate bridges and a router where the bridges only=20 > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From Garg.Pankaj@microsoft.com Mon Nov 25 20:33:21 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD431AE140 for ; Mon, 25 Nov 2013 20:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZzSFRSsuTOD for ; Mon, 25 Nov 2013 20:33:17 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBCE1A1F56 for ; Mon, 25 Nov 2013 20:33:17 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB127.namprd03.prod.outlook.com (10.242.36.27) with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 26 Nov 2013 04:33:09 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.123]) with mapi id 15.00.0820.005; Tue, 26 Nov 2013 04:33:08 +0000 From: Pankaj Garg To: Xuxiaohu , "Bocci, Matthew (Matthew)" , "nvo3@ietf.org" Thread-Topic: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Thread-Index: AQHO4HhUNkyymwLAVUWr5yKvx3oE2pokXrhggBKg/Zw= Date: Tue, 26 Nov 2013 04:33:08 +0000 Message-ID: References: , <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229471@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08229471@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [125.62.209.48] x-forefront-prvs: 00429279BA x-forefront-antispam-report: SFV:NSPM; SFS:(53754006)(199002)(189002)(56816003)(74662001)(76576001)(31966008)(47446002)(77096001)(81342001)(66066001)(80022001)(224313003)(65816001)(81542001)(74502001)(63696002)(76482001)(46102001)(2656002)(87266001)(54316002)(76796001)(79102001)(47976001)(47736001)(49866001)(51856001)(77982001)(74316001)(50986001)(83322001)(19580395003)(19580405001)(74706001)(80976001)(33646001)(4396001)(81816001)(81686001)(16236675002)(85306002)(74876001)(59766001)(56776001)(69226001)(74366001)(224303002)(76786001)(54356001)(53806001)(83072001)(87936001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB127; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:125.62.209.48; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d022ad8a49b04d5686e11eabad930825BY2PR03MB128namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 04:33:21 -0000 --_000_d022ad8a49b04d5686e11eabad930825BY2PR03MB128namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree, NVE-NVE control should be included in the arch document. It provid= es additional value and is required for optimal functioning of VNs in certa= in cases such as cluster failover or other events where a logically central= ized entity like NVA may not be available. Pankaj ________________________________ From: nvo3-bounces@ietf.org on behalf of Xuxiaohu <= xuxiaohu@huawei.com> Sent: Thursday, November 14, 2013 14:27 To: Bocci, Matthew (Matthew); nvo3@ietf.org Subject: [nvo3] ??: Poll for WG adoption and IPR check for draft-narten-nvo= 3-arch-01.txt Hi all, In the current arch draft, there is no mention of NVE-NVE protocol. Does it= mean that there is no need for direct exchange of VN and/or address mappin= g information between NVEs? If so, Does it mean that the control plane mech= anisms used by TRILL or SPB which depend on the NVE-NVE interaction are not= suitable for multi-tenant data center networks anymore, leaving aside whet= her the underlay is IP or not. IMHO, the NVE-NVE protocol is still useful in some small and medium sized m= ulti-tenant data center networks. AFAIK, most tenants within public cloud d= ata centers are small and medium sized enterprises which usually don't need= a lot of VMs. That means the number of NVEs for most VNs would not be very= large especially in the case where the NVE is deployed at physical switche= s, rather than hypervisors/servers. In this case, the VN membership can be = discovered via IGP flooding and the address mapping information of a given = VN could be directly exchanged among NVEs of that VN, without a need for a = dedicated NVA. Best regards, Xiaohu ???: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] ?? Bocci, Matthew= (Matthew) ????: 2013?11?13? 21:58 ???: nvo3@ietf.org ??: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01= .txt This email begins a two week poll to help the chairs judge if there is cons= ensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draf= t. 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. Please consider whether this draft takes the right basic approach, and is a= good basis for the work going forward (and potential future rechartering).= It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies t= o 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 thi= s email whether or not you are aware of any relevant IPR. The draft will no= t be adopted until a response has been received from each author and contri= butor. If you are on the NVO3 WG email list but are not listed as an author or con= tributor, then please explicitly respond only if you are aware of any IPR t= hat has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson --_000_d022ad8a49b04d5686e11eabad930825BY2PR03MB128namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree, NVE-NVE control should be included in the arch document. It pro= vides additional value and is required for optimal functioning of VNs in ce= rtain cases such as cluster failover or other events where a logically cent= ralized entity like NVA may not be available.

Pankaj

From: nvo3-bounces@ietf.org= <nvo3-bounces@ietf.org> on behalf of Xuxiaohu <xuxiaohu@huawei.co= m>
Sent: Thursday, November 14, 2013 14:27
To: Bocci, Matthew (Matthew); nvo3@ietf.org
Subject: [nvo3] 答复: Poll for WG adoption and IPR check= for draft-narten-nvo3-arch-01.txt

Hi all,<= /span>

In the c= urrent arch draft, there is no mention of NVE-NVE protocol. Does it mean th= at there is no need for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control pla= ne mechanisms used by TRILL or SPB which depend on the NVE-NVE interaction = are not suitable for multi-tenant data center networks anymore, leaving asi= de whether the underlay is IP or not.

IMHO, th= e NVE-NVE protocol is still useful in some small and medium sized multi-ten= ant data center networks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually do= n’t need a lot of VMs. That means the number of NVEs for most VNs wou= ld not be very large especially in the case where the NVE is deployed at ph= ysical switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the= address mapping information of a given VN could be directly exchanged amon= g NVEs of that VN, without a need for a dedicated NVA.

Best reg= ards,

Xiaohu

发件人:<= /b> nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] &#= 20195;表 Bocci, Matthew (Matthew)
&#= 21457;送时间: 2= 013&#= 24180;11月13&= #26085; 21:58
收件人: nvo3@ietf.org
主题: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-= 01.txt

This email begins a two week poll to help= the chairs judge if there is consensus to adopt draft-narten-nv= o3-arch-01.txt as an NVO3 working group draft.<= /span>

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

Please also send any comments on the draf= t to the NVO3 list.

Please consider whether this draft takes = the right basic approach, and is a good basis for the work going forward (a= nd potential future rechartering). It does not have to be perfect at this stage.

Coincidentally, we are also polling for k= nowledge 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).<= /p>

If you are listed as a document author or= contributor please respond to this email whether or not you are aware of a= ny 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 Friday 29th November = 2013.

Regards

Matthew and Benson

--_000_d022ad8a49b04d5686e11eabad930825BY2PR03MB128namprd03pro_-- From lucy.yong@huawei.com Tue Nov 26 06:51:27 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A931A802B for ; Tue, 26 Nov 2013 06:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXFkgCDe42wJ for ; Tue, 26 Nov 2013 06:51:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B588C1AC43E for ; Tue, 26 Nov 2013 06:51:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI43162; Tue, 26 Nov 2013 14:51:22 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 14:50:53 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 14:51:19 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 06:51:12 -0800 From: Lucy yong To: David Allan I , "Black, David" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a523IVNUlscF0e/dcGvAwgtkJouGcUAgAAMhYCAACOHAIAD3oGAgABbkACAAIIDwIADAuVAgAAUCUCAARsjAIAAaMdw Date: Tue, 26 Nov 2013 14:51:11 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453020A8@dfweml509-mbx.china.huawei.com> References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 14:51:27 -0000 David, Please see inline. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com]=20 Sent: Monday, November 25, 2013 6:30 PM To: Lucy yong; Black, David Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, Any non-interconnect of tenant networks in a common routing implementation = will require lots of ACLs which can be gotten wrong, and would not permit r= euse of private addressing by multiple tenants sharing a router FDB....and = could be messed up by duplicate MAC addresses. [Lucy] agreed. SHOULD not use ACL doing that.=20 IMO it is a bad idea, it places a lot of constraints on virtualization (e.g= . it can only work if..and if... and if...etc.) so it becomes somewhat half= baked.=20 If a tenant requires multiple interconnected subnets they need their own VR= F/VR implementation, own ARP cache etc to obviate the potential problems. W= hy would we WANT to allow otherwise? [Lucy] Agreed. But NVO3 goal is the solution in multi-tenancy environment. = Network virtualization needs to figure out an efficient and secure way to i= mplement it. Software can do a lot. :)=20 Thanks, Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Monday, November 25, 2013 8:12 AM To: Black, David Cc: nvo3@ietf.org Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi David, Please see inline. -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Monday, November 25, 2013 8:36 AM To: Lucy yong Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result th= at there can be multiple instances of the router function in the same physi= cal network node in multiple IP address spaces. [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we t= alk about a router device with bridge capability (i.e. IRB), Isn't such dev= ice operated under one L3 address space, including physical network address= space and source/destination address space? In other words, endpoint and p= hysical network are on the same address space. In traditional DC environmen= t, even VLAN can provide virtual networks, MAC address is uniquely assigned= to physical device, so it is effectively only one MAC address space regard= less whether VLAN is used or not. VLAN provides a virtual private network, = it was not originally intended to provide independent address spaces. =20 > Second, an NVE has both VAP interfaces and overlay tunnel interfaces=20 > plus internal gw interface. A router only has ports or L2 interfaces,=20 > which are equivalent to the VAPs on NVE case. (you point out this) I think this is over-simplified. A router has interfaces that correspond t= o both overlay tunnel interfaces and its internal gateway (not sure whether= this was intended to be the gateway facing end systems, or the interface t= hat "default" is pointed at, if applicable, but the analogy holds for both). For a non-o= verlay environment, these interfaces are not encapsulated, but in general, = a router has L2/link connectivity to other routers, not just end systems. [Lucy] I may over-simplify the router to focus on this case only. My point = is that the router device in this case typically handles one L3 address spa= ce and one MAC address space in the reality.=20 Lucy > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . And a physical routing implementation may provide logically distinct routin= g for multiple VLANs. > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy,=20 > the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). Second, an NVE has both VAP=20 > interfaces and overlay tunnel interfaces plus internal gw interface. > A router only has ports or L2 interfaces, which are equivalent to the=20 > VAPs on NVE case. (you point out this) >=20 > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't. > Furthermore the policy may have finer granularity to a level. For=20 > example, between L2VNx and L2VNy, the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. >=20 > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. =20 > The quoted text was intended to head in that direction, so an explicit st= atement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there=20 > was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner=20 > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > switches/routers process packets i.e. based on frame's destination=20 > > MAC and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > bridge-route-bridge. A received multicast packet might need to be=20 > > bridged out other L2 ports in the same bridge domain. Then one copy=20 > > of packet is passed to the L3 function, which does L3 multicast=20 > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given > > L3 oIF might correspond to a bridge domain i.e., multiple packets=20 > > might need to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3=20 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally=20 > > consistent with separate bridges and a router where the bridges only=20 > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From narten@us.ibm.com Tue Nov 26 08:58:07 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC81ADF55 for ; Tue, 26 Nov 2013 08:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VtgeuWP6co4 for ; Tue, 26 Nov 2013 08:58:05 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 57E331ADF32 for ; Tue, 26 Nov 2013 08:58:05 -0800 (PST) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Nov 2013 11:58:04 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 26 Nov 2013 11:58:02 -0500 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id DAC1038C803B for ; Tue, 26 Nov 2013 11:57:59 -0500 (EST) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAQGw1i156950786 for ; Tue, 26 Nov 2013 16:58:01 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAQGw03I031470 for ; Tue, 26 Nov 2013 11:58:00 -0500 Received: from cichlid.raleigh.ibm.com ([9.49.221.66]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAQGvwsQ031298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Nov 2013 11:57:59 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAQGvwtR023978 for ; Tue, 26 Nov 2013 11:57:58 -0500 Message-Id: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> From: Thomas Narten To: nvo3@ietf.org Date: Tue, 26 Nov 2013 11:57:57 -0500 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112616-7182-0000-0000-00000935C857 Subject: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 16:58:07 -0000 Hi. In precisely defining L3 service, one question that comes up is how is the TTL treated. That is, say NVO3 provides L3 VN service to a TS. When TSes on the VN communicate with each other, they are always using IP. What happens to the TTL in such packets? I see several choices: a) do not decrement the TTL at all. Treat the TSes as if they were directly attached to each other (i.e., on the same link) b) Decrement by 1... c) Decrement by some random amount.. :-) Some protocols may care about TTL handling. IPv6 Neighbor Discovery, for example, requires that ND packets be dropped if they are received with a TTL other than 255 (i.e., they'd require choice a). I think some other routing protocols do the same (as a way to ignore packets from offlink "attackers"). What do tenants of an L3 service expect? Do they care (other than in cases like ND)? Can we just define L3 service as saying the TTL of tenant packets are not modified by NVO3? Any advice from L3 service providers that already provide such services today? Thomas From farinacci@gmail.com Tue Nov 26 09:28:57 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935BF1ADF6C for ; Tue, 26 Nov 2013 09:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlnZTt1nWcoW for ; Tue, 26 Nov 2013 09:28:56 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 076041ADF59 for ; Tue, 26 Nov 2013 09:28:56 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id md12so8475270pbc.35 for ; Tue, 26 Nov 2013 09:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F4mmlXZ7gDX5lSSnjvlqORm59Knkt579VHBhSzcCoWY=; b=Bj4gVyBeJaNKWD1dORRdqL9uvl93XmIO0JeF/4C+merq2yalYLHNxM5pjMTZQXUsuB JFbyXZlzAnYwoXry7K/7fXoEJgat2LD7SD+uZu5brXlUHCXXIoJchvlOm+9NB8z4g/r7 Wf6BXVyudB+W3fTknwz2+Oxzn/QOzVrhy/V4esdSOiLJEojMfABJthNBij8QQEZdJP38 I6rRYlEGOmNTxO1u3zQ1hDfwoTGpIa7qgzSEemWy/4mbD/gSOEaJXp9JSjgORdA7yjGD SKafOfIQzp8TGq6nt4T+tqYPppZWsuKqVt/e/cHn71Nky2YvYF+7KjCC79lGej3xE8ZW Dz+w== X-Received: by 10.66.180.200 with SMTP id dq8mr37212030pac.104.1385486935982; Tue, 26 Nov 2013 09:28:55 -0800 (PST) Received: from [192.168.1.12] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id so2sm82015717pbc.5.2013.11.26.09.28.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 09:28:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> Date: Tue, 26 Nov 2013 09:28:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1822) Cc: nvo3@ietf.org Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:28:57 -0000 Thomas, there is plenty of discussion on TTL handling for LISP in RFC = 6830. And at the same time, you have to decide what traceroute behavior = you want. You need to decide if tunnels are 1-hop or n hops. MPLS chose = 1-hop tunnels but product configuration knobs could change the behavior. = LISP choose n-hops because operators gave us requirements to see the = entire path. You will have to ask this question for QOS/TOS handling as well. David = Black contributed text to the LISP working group, so you can see the = resulting decisions in RFC 6830. Dino On Nov 26, 2013, at 8:57 AM, Thomas Narten wrote: > Hi. >=20 > In precisely defining L3 service, one question that comes up is how is > the TTL treated. That is, say NVO3 provides L3 VN service to a > TS. When TSes on the VN communicate with each other, they are always > using IP. What happens to the TTL in such packets? >=20 > I see several choices: >=20 > a) do not decrement the TTL at all. Treat the TSes as if they were = directly > attached to each other (i.e., on the same link) >=20 > b) Decrement by 1... >=20 > c) Decrement by some random amount.. :-) >=20 > Some protocols may care about TTL handling. IPv6 Neighbor Discovery, > for example, requires that ND packets be dropped if they are received > with a TTL other than 255 (i.e., they'd require choice a). I think > some other routing protocols do the same (as a way to ignore packets > from offlink "attackers"). >=20 > What do tenants of an L3 service expect? Do they care (other than in > cases like ND)? >=20 > Can we just define L3 service as saying the TTL of tenant packets are > not modified by NVO3? >=20 > Any advice from L3 service providers that already provide such > services today? >=20 > Thomas >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From narten@us.ibm.com Tue Nov 26 11:43:15 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAF91ADFAC for ; Tue, 26 Nov 2013 11:43:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5LI1BuvKw4z for ; Tue, 26 Nov 2013 11:43:14 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 289F41ADF96 for ; Tue, 26 Nov 2013 11:43:14 -0800 (PST) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Nov 2013 12:43:13 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 26 Nov 2013 12:43:12 -0700 Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4D88F19D803E for ; Tue, 26 Nov 2013 12:43:06 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp07028.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAQHfABK7471506 for ; Tue, 26 Nov 2013 18:41:10 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAQJhBHZ018487 for ; Tue, 26 Nov 2013 12:43:11 -0700 Received: from cichlid.raleigh.ibm.com ([9.49.221.66]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAQJh9U5018332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Nov 2013 12:43:11 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAQJh8HI016985; Tue, 26 Nov 2013 14:43:09 -0500 Message-Id: <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> To: Dino Farinacci In-reply-to: <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Tue, 26 Nov 2013 09:28:52 -0800." Date: Tue, 26 Nov 2013 14:43:08 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112619-0928-0000-0000-000003D048EB Cc: nvo3@ietf.org Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 19:43:15 -0000 Hi Dino. I'm not really asking about TTL processing for tunnels in general... I'm asking specifically in the context of virtual network service, where tenants are connecting to virtual networks expecting either L2 or L3 service. What expectations to the TSes have when it comes to TTL modification? In the L2 case, tenatnts expect to be given service equivalent to an L2 broadcast domain. I.e., nodes can talk directly to each other at the L2 level using unicast/multicast. This is what we usually think of as being attached to a shared "link". But what if the service being provided is L3? In this case TSes are only sending IP packets, but all TSes are directly reachable (i.e., without leaving the VN). What expectation do TSes in this type of situation expect of the TTL processing? Do they even care? Thomas From david.i.allan@ericsson.com Tue Nov 26 13:31:26 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFE81ADF9A for ; Tue, 26 Nov 2013 13:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_55=1, J_CHICKENPOX_66=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcnFBINdrBfX for ; Tue, 26 Nov 2013 13:31:22 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9212F1AD8EB for ; Tue, 26 Nov 2013 13:31:21 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-51-529513266f96 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C0.8E.23183.62315925; Tue, 26 Nov 2013 22:31:18 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 26 Nov 2013 16:31:19 -0500 From: David Allan I To: Lucy yong , "Black, David" Thread-Topic: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Thread-Index: AQHO5a5z2g7UpXJ/FEupqKV7wmC9AZot53oAgAAMhoCAACOGAIAD3oGAgABbkACAAydmgIAA5ssAgAAavICAADTD8IABRxKA///y3OA= Date: Tue, 26 Nov 2013 21:31:19 +0000 Message-ID: References: <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFDEC@SJEXCHMB09.corp.ad.broadcom.com> <3C086BA39C55B9418AE8FEA3F3EFDEC42AEFFEA3@SJEXCHMB09.corp.ad.broadcom.com> <528FAC9D.6090202@acm.org> <8D3D17ACE214DC429325B2B98F3AE712026ADFA7A7@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301A22@dfweml509-mbx.china.huawei.com> <8D3D17ACE214DC429325B2B98F3AE712026ADFA8A9@MX15A.corp.emc.com> <2691CE0099834E4A9C5044EEC662BB9D45301C11@dfweml509-mbx.china.huawei.com> <2691CE0099834E4A9C5044EEC662BB9D453020A8@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453020A8@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPgq6a8NQgg297zS22Hl7LbrHx1yI2 i6fzJR2YPY4cmc3i0XLkLavHkiU/mQKYo7hsUlJzMstSi/TtErgy5nw7xlTQHF/xe9E+1gbG bd5djJwcEgImEic2zWSBsMUkLtxbz9bFyMUhJHCEUeJ1yy0WCGc5o8Srg8uZQKrYBAwk9vz/ wghiiwh4SdxqaAAq4uBgFlCWaO60BgkLC7hL3Lu2jRWixEOic+czqPIyiXnzJ4HZLAKqEtuX LgWzeQV8JbZcm84Esesuq0T7rV1guzgFwiSuP5oLdh0j0HXfT60BizMLiEvcejKfCeJqAYkl e84zQ9iiEi8f/2OFsJUlvs95xAJRryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVFsFpKxs5C0 zELSMgtJywJGllWMHKXFqWW56UYGmxiBkXNMgk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwFh49ow0z7z45E+srOL3XqtXKf6I+X5F+MHh/syenrjZG3/f apqlGLQhdirHzJLkRZ9j+FM49LgrGTSkEotvf4m5HViw40309tR9vTqbC6Vq1i4pyph6/fGE u8E2pZLHPq7wOT3pkYPDha3TlT6a/7R5srev64/sztRTq5/eq/zz6t9KqaWLNiUpsRRnJBpq MRcVJwIAMZLuUWoCAAA= Cc: "nvo3@ietf.org" Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 21:31:26 -0000 HI Lucy: Your point completely escapes me. Could you clarify? Cheers Dave -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com]=20 Sent: Tuesday, November 26, 2013 6:51 AM To: David Allan I; Black, David Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service David, Please see inline. -----Original Message----- From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: Monday, November 25, 2013 6:30 PM To: Lucy yong; Black, David Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, Any non-interconnect of tenant networks in a common routing implementation = will require lots of ACLs which can be gotten wrong, and would not permit r= euse of private addressing by multiple tenants sharing a router FDB....and = could be messed up by duplicate MAC addresses. [Lucy] agreed. SHOULD not use ACL doing that.=20 IMO it is a bad idea, it places a lot of constraints on virtualization (e.g= . it can only work if..and if... and if...etc.) so it becomes somewhat half= baked.=20 If a tenant requires multiple interconnected subnets they need their own VR= F/VR implementation, own ARP cache etc to obviate the potential problems. W= hy would we WANT to allow otherwise? [Lucy] Agreed. But NVO3 goal is the solution in multi-tenancy environment. = Network virtualization needs to figure out an efficient and secure way to i= mplement it. Software can do a lot. :)=20 Thanks, Lucy My 2 cents Dave -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lucy yong Sent: Monday, November 25, 2013 8:12 AM To: Black, David Cc: nvo3@ietf.org Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Hi David, Please see inline. -----Original Message----- From: Black, David [mailto:david.black@emc.com] Sent: Monday, November 25, 2013 8:36 AM To: Lucy yong Cc: nvo3@ietf.org Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3 Service Lucy, > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). I firmly disagree. VLANs can be used for multi-tenancy, with the result th= at there can be multiple instances of the router function in the same physi= cal network node in multiple IP address spaces. [Lucy] Yes, VLANs can be used for multi-tenancy. But, in this context, we t= alk about a router device with bridge capability (i.e. IRB), Isn't such dev= ice operated under one L3 address space, including physical network address= space and source/destination address space? In other words, endpoint and p= hysical network are on the same address space. In traditional DC environmen= t, even VLAN can provide virtual networks, MAC address is uniquely assigned= to physical device, so it is effectively only one MAC address space regard= less whether VLAN is used or not. VLAN provides a virtual private network, = it was not originally intended to provide independent address spaces. =20 > Second, an NVE has both VAP interfaces and overlay tunnel interfaces=20 > plus internal gw interface. A router only has ports or L2 interfaces,=20 > which are equivalent to the VAPs on NVE case. (you point out this) I think this is over-simplified. A router has interfaces that correspond t= o both overlay tunnel interfaces and its internal gateway (not sure whether= this was intended to be the gateway facing end systems, or the interface t= hat "default" is pointed at, if applicable, but the analogy holds for both). For a non-o= verlay environment, these interfaces are not encapsulated, but in general, = a router has L2/link connectivity to other routers, not just end systems. [Lucy] I may over-simplify the router to focus on this case only. My point = is that the router device in this case typically handles one L3 address spa= ce and one MAC address space in the reality.=20 Lucy > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . And a physical routing implementation may provide logically distinct routin= g for multiple VLANs. > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't Likewise for routing and VLANs. > Furthermore the policy may have > finer granularity to a level. For example, between L2VNx and L2VNy,=20 > the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. > > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. And also likewise for routing and VLANs. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Sunday, November 24, 2013 7:50 PM > To: Black, David; Erik Nordmark > Cc: nvo3@ietf.org > Subject: RE: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Here is my 2cent whether combined L2/L3 service is architecturally=20 > same or different from the non-overlay IRB case used today. >=20 > They are the same in term of the function feature, i.e. a router can=20 > provide bridging capability for intra VLAN traffic, and bridging=20 > capability for inter VLANs traffic via routing. >=20 > But they have differences too. First, an NVE supports this feature in=20 > term of multi-tenancy environment, while a route does it in a single=20 > tenancy case (in one address space only). Second, an NVE has both VAP=20 > interfaces and overlay tunnel interfaces plus internal gw interface. > A router only has ports or L2 interfaces, which are equivalent to the=20 > VAPs on NVE case. (you point out this) >=20 > In a multi-tenancy environment, an NVE may be the member for multiple VNs= . > Some VN may have independent address spaces, some may share the same=20 > address space. An NVE needs to have a VN interconnection policy table=20 > which indicates which VNs can communicate and which VNs can't. > Furthermore the policy may have finer granularity to a level. For=20 > example, between L2VNx and L2VNy, the policy > is: for unicast traffic, L2VNx->L2VNy permit; L2VNx<-L2VNy via a=20 > firewall; for multicast traffic, L2VNx<->L2VNy not permit. >=20 > IMO: the inter-VN policy should be controlled at the VN level, not to=20 > the particular address (ACL level) or particular application (TCP,=20 > HTTP level) in the VNs. The latter belongs to the firewall function. >=20 > Lucy >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, November 22, 2013 6:40 PM > To: Erik Nordmark > Cc: nvo3@ietf.org > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > Service >=20 > Writing as an individual, not co-author of draft-narten-nvo3-arch: >=20 > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. >=20 > IMHO, it should be architecturally the same, and we should say so. =20 > The quoted text was intended to head in that direction, so an explicit st= atement > seems like a fine idea. I think the touchstone for how L3 service is > provided > in an L2/L3 service combination should be: "what would happen if there=20 > was no network virtualization?" >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Erik Nordmark > > Sent: Friday, November 22, 2013 2:12 PM > > To: Pankaj Garg; Vivek Kumar; Larry Kreeger (kreeger); Lucy yong;=20 > > Thomas Narten > > Cc: nvo3@ietf.org; Linda Dunbar > > Subject: Re: [nvo3] Fwd: Arch: proposed text for Combined L2/L3=20 > > Service > > > > On 11/20/13 12:07 AM, Pankaj Garg wrote: > > > Wouldn't the decision to do L2 or L3 service be based on the inner=20 > > > frame > > fields i.e. destination MAC/IP in the inner frame? Similar to how=20 > > switches/routers process packets i.e. based on frame's destination=20 > > MAC and destination IP address (if present)? > > > > > > IMHO, Thomas's original text (pasted below) describes this quite=20 > > > well and > > concisely. > > > > > >>> > > >>> A virtual network can also provide a combined L2 and L3 > > >>> service to tenants. In such cases, a tenant sends and > > >>> receives both L2 and L3 packets. An NVE recieving packe= ts > > >>> from a TS determines the type of service to be applied = to > > >>> the packet on a per-packet basis as indicated by the > > >>> packet's destination MAC address as provided by the TS.= If > > >>> the MAC address corresponds to that of an L3 router (as > > >>> determined by the NVE), traffic is given L3 > > >>> semantics. Otherwise, the packet is given L2 service > > >>> semantics. A combined L2/L3 service presents no special > > >>> considerations for NVO3, other than packets received fr= om a > > >>> tenant must be classified as to what type of service th= ey > > >>> are to be given before they can be processed. > > >>> > > > > What is missing for me is a higher-level statement whether or not we=20 > > see an NVE providing combined L2 and L3 service as being=20 > > architecturally different that the non-overlay case of a > > bridge+router that provides combined service L2 and L3 today. > > > > If we think it is just the same architecturally, then it would make=20 > > sense to state that. If we think it is different, then I think we=20 > > need more details that Thomas' text above. > > > > FWIW the existing bridge+routers handle multicast conceptually as=20 > > bridge-route-bridge. A received multicast packet might need to be=20 > > bridged out other L2 ports in the same bridge domain. Then one copy=20 > > of packet is passed to the L3 function, which does L3 multicast=20 > > routing (check iIF, decrement ttl, determine oIFs). Finally, a given > > L3 oIF might correspond to a bridge domain i.e., multiple packets=20 > > might need to be sent out different L2 ports for each oIF. > > > > While that is a bit complex, it is a lot better if the NVO3=20 > > architecture is the same as existing combined bridge+router boxes. > > > > And note that an existing combined bridge+router is architecturally=20 > > consistent with separate bridges and a router where the bridges only=20 > > do > > L2 and the router only does L3. > > > > Erik > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From farinacci@gmail.com Tue Nov 26 13:45:19 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBF71ADF7A for ; Tue, 26 Nov 2013 13:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CSQrtI8GLbQ for ; Tue, 26 Nov 2013 13:45:17 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 232E91ACC89 for ; Tue, 26 Nov 2013 13:45:17 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so8961633pbc.29 for ; Tue, 26 Nov 2013 13:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Oxr1/BcEdk2Cu3ZpwOswSzLcH1SlcivzzLiqOp15Fds=; b=WXqxJmFTDUUDkezPSau6BkZFD3JPIBZIzPNSuk8kULdwcQJISOErZaW3LUc8Fo77Vs znNpaK7+8NvvsLD0hF7goAxn3l1yS6kQHSEs+D9K1v0L6IWVVB++2Nf/giqUyFTXjG1S YgDGNpyo8G8N0CiTJea/U37WXL3yQ5fbobus33Hw4ohqg5W1Hltz+L3yIWg3K/6AhaMv zS4BlVz+RBTJB0jkZIscuqaGqo3qMq4m++8pQvBrxULKHlbcfXIzP3zXoOmT7OlxMsgh HjYnMz3j3KttMvBU/3808J2JgtKwstmR8632xglDTYyDlhkoPmi1Zb+P5YObnBjnQOBG aspg== X-Received: by 10.66.218.226 with SMTP id pj2mr37765680pac.62.1385502316979; Tue, 26 Nov 2013 13:45:16 -0800 (PST) Received: from [10.104.60.247] (mobile-166-137-184-102.mycingular.net. [166.137.184.102]) by mx.google.com with ESMTPSA id y9sm93984372pas.10.2013.11.26.13.45.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 13:45:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B554a) In-Reply-To: <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> Date: Tue, 26 Nov 2013 13:45:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> To: Thomas Narten Cc: "nvo3@ietf.org" Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 21:45:20 -0000 > Hi Dino. >=20 > I'm not really asking about TTL processing for tunnels in > general... I'm asking specifically in the context of virtual network > service, where tenants are connecting to virtual networks expecting > either L2 or L3 service. What expectations to the TSes have when it > comes to TTL modification? I think it is exactly the same case.=20 > In the L2 case, tenatnts expect to be given service equivalent to an > L2 broadcast domain. I.e., nodes can talk directly to each other at > the L2 level using unicast/multicast. This is what we usually think of > as being attached to a shared "link". Right - but for a L2 service there is no TTL to decrement in the NVE since i= t forwards a packet based on a MAC header.=20 > But what if the service being provided is L3? In this case TSes are > only sending IP packets, but all TSes are directly reachable (i.e., > without leaving the VN). What expectation do TSes in this type of > situation expect of the TTL processing? "Directly" needs to be defined above. If the two TSes are in the same subnet= then it would behave as it does today (when 2 hosts are connected to hub - I= don't say switch because I don't want to complicate the discussion).=20 > Do they even care? If I am 10.0.0.1 in CA on subnet 10.0.0.0/8 and you are 10.0.0.2 in NY on su= bnet 10.0.0.0/8 and we are reachable via the overlay, I expect one line if o= utput from traceroute. If you are 11.0.0.1 I expect at least 2 lines of outp= ut.=20 Dino >=20 > Thomas >=20 From nordmark@acm.org Tue Nov 26 14:33:17 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D95D1ADFA6 for ; Tue, 26 Nov 2013 14:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb1_aaTTfEbu for ; Tue, 26 Nov 2013 14:33:16 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7D1ADE72 for ; Tue, 26 Nov 2013 14:33:15 -0800 (PST) Received: from [172.22.251.17] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rAQMXCRx011023 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 26 Nov 2013 14:33:12 -0800 Message-ID: <529521A9.1070905@acm.org> Date: Tue, 26 Nov 2013 14:33:13 -0800 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Dino Farinacci , Thomas Narten References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> In-Reply-To: <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;UtPyu+pW4xG8EWE96sd3kQ== M;WkwIvOpW4xG8EWE96sd3kQ== Cc: "nvo3@ietf.org" Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:33:17 -0000 On 11/26/13 1:45 PM, Dino Farinacci wrote: >> But what if the service being provided is L3? In this case TSes are >> only sending IP packets, but all TSes are directly reachable (i.e., >> without leaving the VN). What expectation do TSes in this type of >> situation expect of the TTL processing? Thomas, I think there are two different ways to view an L3 service: 1. A closed user group which is larger than a single IP subnet, provisioned as part of setting up the VN. 2. A more efficient way to pass around IP packets; no need to have an (inner) Ethernet header if the TSs only care about IP. I reality it is a combination of the two. The administrator that provisions the VN see the CUG aspect of #1. The TS and NVE implementations see the #2. > "Directly" needs to be defined above. If the two TSes are in the same subnet then it would behave as it does today (when 2 hosts are connected to hub - I don't say switch because I don't want to complicate the discussion). > >> Do they even care? > > If I am 10.0.0.1 in CA on subnet 10.0.0.0/8 and you are 10.0.0.2 in NY on subnet 10.0.0.0/8 and we are reachable via the overlay, I expect one line if output from traceroute. If you are 11.0.0.1 I expect at least 2 lines of output. Dino, I think what you are saying is that from a host/TS perspective you'd expect an L3 service to have the same TTL behavior as when using a L2 service with routers that are external to the VN. That makes a lot of sense to me. In that way the size and shape of the L3 VN/CUG doesn't impact the TTL handling. Erik From farinacci@gmail.com Tue Nov 26 16:04:02 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFA21AE038 for ; Tue, 26 Nov 2013 16:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTkdriZ9nQXO for ; Tue, 26 Nov 2013 16:04:01 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 27BFB1AD698 for ; Tue, 26 Nov 2013 16:04:01 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id i72so4565012yha.11 for ; Tue, 26 Nov 2013 16:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0sFlQbnDVg6iSxs0joJANddkC1cSaLYbRSmH40rC7D0=; b=Rh35AecDWy82CUqcn4uX9vaF/Swl+uzZgNvMD9tK59RqJ92h5/8ik3vcDpnWTmsoRQ swq1rttt/qYEKGt90GRwyA/mCIjZIN5cMjdrd0LjQeW1vj7Pp7odNj+IpLhlY0KV+72S 854+chtFgiq+utskawvPaxNiRaIfOeoVg2VD2B55Fvllq1+91iGvNm9YhW1iQdGrLcA/ b92jF+ITW8WoSuqO8T3cC5cCQTguB+gulYK/otPyrGRy3PBlRoYpquDb62i4CEbkf5XS btpq5K8MV4c9d8wuiQWKH0wT2t0Uw0ijt7yOi0G9XgUQBCygR9e8wq4qhHY35YjjSzC9 LSQQ== X-Received: by 10.236.117.103 with SMTP id i67mr20581553yhh.7.1385510640843; Tue, 26 Nov 2013 16:04:00 -0800 (PST) Received: from ?IPv6:2602:306:37fe:1cc0:15a9:4eda:ad7b:8f89? ([2602:306:37fe:1cc0:15a9:4eda:ad7b:8f89]) by mx.google.com with ESMTPSA id o27sm86184166yhb.19.2013.11.26.16.03.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 16:04:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <529521A9.1070905@acm.org> Date: Tue, 26 Nov 2013 16:03:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B74425A-6C4F-4D01-895B-4CE7A4E9D96A@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> <529521A9.1070905@acm.org> To: Erik Nordmark X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 00:04:02 -0000 > Dino, >=20 > I think what you are saying is that from a host/TS perspective you'd = expect an L3 service to have the same TTL behavior as when using a L2 = service with routers that are external to the VN. > That makes a lot of sense to me. Right, that is what I am saying. > In that way the size and shape of the L3 VN/CUG doesn't impact the TTL = handling. Right. Dino From xuxiaohu@huawei.com Tue Nov 26 17:47:24 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C811AC3DA for ; Tue, 26 Nov 2013 17:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG8_jD55Fgvi for ; Tue, 26 Nov 2013 17:47:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF81A8026 for ; Tue, 26 Nov 2013 17:47:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI77802; Wed, 27 Nov 2013 01:47:20 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 01:46:53 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 01:47:19 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 09:47:15 +0800 From: Xuxiaohu To: Thomas Narten , "nvo3@ietf.org" Thread-Topic: [nvo3] TTL handling in an L3 service Thread-Index: AQHO6sizzAw8KGV/Hk62HkBEakS2Lpo4TkTA Date: Wed, 27 Nov 2013 01:47:14 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238868@NKGEML512-MBS.china.huawei.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> In-Reply-To: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFRUTCBoYW5kbGluZyAgaW4gYW4gTDMgc2Vy?= =?gb2312?b?dmljZQ==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 01:47:24 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMyBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBUaG9tYXMgTmFydGVuDQo+ILeiy83KsbzkOiAyMDEzxOoxMdTC MjfI1SAwOjU4DQo+IMrVvP7IyzogbnZvM0BpZXRmLm9yZw0KPiDW98ziOiBbbnZvM10gVFRMIGhh bmRsaW5nIGluIGFuIEwzIHNlcnZpY2UNCj4gDQo+IEhpLg0KPiANCj4gSW4gcHJlY2lzZWx5IGRl ZmluaW5nIEwzIHNlcnZpY2UsIG9uZSBxdWVzdGlvbiB0aGF0IGNvbWVzIHVwIGlzIGhvdyBpcyB0 aGUgVFRMDQo+IHRyZWF0ZWQuIFRoYXQgaXMsIHNheSBOVk8zIHByb3ZpZGVzIEwzIFZOIHNlcnZp Y2UgdG8gYSBUUy4gV2hlbiBUU2VzIG9uIHRoZSBWTg0KPiBjb21tdW5pY2F0ZSB3aXRoIGVhY2gg b3RoZXIsIHRoZXkgYXJlIGFsd2F5cyB1c2luZyBJUC4gV2hhdCBoYXBwZW5zIHRvIHRoZQ0KPiBU VEwgaW4gc3VjaCBwYWNrZXRzPw0KPiANCj4gSSBzZWUgc2V2ZXJhbCBjaG9pY2VzOg0KPiANCj4g YSkgZG8gbm90IGRlY3JlbWVudCB0aGUgVFRMIGF0IGFsbC4gVHJlYXQgdGhlIFRTZXMgYXMgaWYg dGhleSB3ZXJlIGRpcmVjdGx5DQo+ICAgIGF0dGFjaGVkIHRvIGVhY2ggb3RoZXIgKGkuZS4sIG9u IHRoZSBzYW1lIGxpbmspDQo+IA0KPiBiKSBEZWNyZW1lbnQgYnkgMS4uLg0KPiANCj4gYykgRGVj cmVtZW50IGJ5IHNvbWUgcmFuZG9tIGFtb3VudC4uIDotKQ0KPiANCj4gU29tZSBwcm90b2NvbHMg bWF5IGNhcmUgYWJvdXQgVFRMIGhhbmRsaW5nLiBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSwgZm9y DQo+IGV4YW1wbGUsIHJlcXVpcmVzIHRoYXQgTkQgcGFja2V0cyBiZSBkcm9wcGVkIGlmIHRoZXkg YXJlIHJlY2VpdmVkIHdpdGggYSBUVEwNCj4gb3RoZXIgdGhhbiAyNTUgKGkuZS4sIHRoZXknZCBy ZXF1aXJlIGNob2ljZSBhKS4gSSB0aGluayBzb21lIG90aGVyIHJvdXRpbmcNCj4gcHJvdG9jb2xz IGRvIHRoZSBzYW1lIChhcyBhIHdheSB0byBpZ25vcmUgcGFja2V0cyBmcm9tIG9mZmxpbmsgImF0 dGFja2VycyIpLg0KDQpIaSBUaG9tYXMsDQoNCkkgdGhpbmsgaXQncyB3b3J0aHdoaWxlIHRvIGRp c2N1c3MgdGhlIFRUTCBoYW5kbGluZyBpc3N1ZSBhc3NvY2lhdGVkIHdpdGggTDMgc2VydmljZSBv ciBMMyBvdmVybGF5LiBIb3dldmVyLCB0aGUgYWJvdmUgZXhhbXBsZSAoaS5lLiwgTkQpIGlzIG5v dCBhY2N1cmF0ZSBzaW5jZSBpdCBzZWVtcyBubyBuZWVkIHRvIHRyYW5zcG9ydCB0aGUgTkQgbWVz c2FnZXMgYWNyb3NzIGEgTGF5ZXIzIG92ZXJsYXkuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IFdoYXQgZG8gdGVuYW50cyBvZiBhbiBMMyBzZXJ2aWNlIGV4cGVjdD8gRG8gdGhleSBjYXJl IChvdGhlciB0aGFuIGluIGNhc2VzIGxpa2UNCj4gTkQpPw0KPiANCj4gQ2FuIHdlIGp1c3QgZGVm aW5lIEwzIHNlcnZpY2UgYXMgc2F5aW5nIHRoZSBUVEwgb2YgdGVuYW50IHBhY2tldHMgYXJlIG5v dA0KPiBtb2RpZmllZCBieSBOVk8zPw0KPiANCj4gQW55IGFkdmljZSBmcm9tIEwzIHNlcnZpY2Ug cHJvdmlkZXJzIHRoYXQgYWxyZWFkeSBwcm92aWRlIHN1Y2ggc2VydmljZXMgdG9kYXk/DQo+IA0K PiBUaG9tYXMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From xuxiaohu@huawei.com Tue Nov 26 17:53:06 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FD71ADFC4 for ; Tue, 26 Nov 2013 17:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO-BhSJtVv46 for ; Tue, 26 Nov 2013 17:53:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0B51A8026 for ; Tue, 26 Nov 2013 17:53:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI78064; Wed, 27 Nov 2013 01:53:03 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 01:52:33 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 01:53:03 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 09:52:52 +0800 From: Xuxiaohu To: Xuxiaohu , Thomas Narten , "nvo3@ietf.org" Thread-Topic: [nvo3] TTL handling in an L3 service Thread-Index: AQHO6sizzAw8KGV/Hk62HkBEakS2Lpo4TkTAgAABqLA= Date: Wed, 27 Nov 2013 01:52:51 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFRUTCBoYW5kbGluZyAgaW4gYW4gTDMgc2Vy?= =?gb2312?b?dmljZQ==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 01:53:06 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqxvOQ6 IDIwMTPE6jEx1MIyN8jVIDk6NDcNCj4gytW8/sjLOiAnVGhvbWFzIE5hcnRlbic7IG52bzNAaWV0 Zi5vcmcNCj4g1vfM4jogtPC4tDogW252bzNdIFRUTCBoYW5kbGluZyBpbiBhbiBMMyBzZXJ2aWNl DQo+IA0KPiANCj4gDQo+ID4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4gt6K8/sjLOiBudm8zIFtt YWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFRob21hcyBOYXJ0ZW4NCj4gPiC3osvN yrG85DogMjAxM8TqMTHUwjI3yNUgMDo1OA0KPiA+IMrVvP7IyzogbnZvM0BpZXRmLm9yZw0KPiA+ INb3zOI6IFtudm8zXSBUVEwgaGFuZGxpbmcgaW4gYW4gTDMgc2VydmljZQ0KPiA+DQo+ID4gSGku DQo+ID4NCj4gPiBJbiBwcmVjaXNlbHkgZGVmaW5pbmcgTDMgc2VydmljZSwgb25lIHF1ZXN0aW9u IHRoYXQgY29tZXMgdXAgaXMgaG93IGlzDQo+ID4gdGhlIFRUTCB0cmVhdGVkLiBUaGF0IGlzLCBz YXkgTlZPMyBwcm92aWRlcyBMMyBWTiBzZXJ2aWNlIHRvIGEgVFMuDQo+ID4gV2hlbiBUU2VzIG9u IHRoZSBWTiBjb21tdW5pY2F0ZSB3aXRoIGVhY2ggb3RoZXIsIHRoZXkgYXJlIGFsd2F5cyB1c2lu Zw0KPiA+IElQLiBXaGF0IGhhcHBlbnMgdG8gdGhlIFRUTCBpbiBzdWNoIHBhY2tldHM/DQo+ID4N Cj4gPiBJIHNlZSBzZXZlcmFsIGNob2ljZXM6DQo+ID4NCj4gPiBhKSBkbyBub3QgZGVjcmVtZW50 IHRoZSBUVEwgYXQgYWxsLiBUcmVhdCB0aGUgVFNlcyBhcyBpZiB0aGV5IHdlcmUgZGlyZWN0bHkN Cj4gPiAgICBhdHRhY2hlZCB0byBlYWNoIG90aGVyIChpLmUuLCBvbiB0aGUgc2FtZSBsaW5rKQ0K PiA+DQo+ID4gYikgRGVjcmVtZW50IGJ5IDEuLi4NCj4gPg0KPiA+IGMpIERlY3JlbWVudCBieSBz b21lIHJhbmRvbSBhbW91bnQuLiA6LSkNCj4gPg0KPiA+IFNvbWUgcHJvdG9jb2xzIG1heSBjYXJl IGFib3V0IFRUTCBoYW5kbGluZy4gSVB2NiBOZWlnaGJvciBEaXNjb3ZlcnksDQo+ID4gZm9yIGV4 YW1wbGUsIHJlcXVpcmVzIHRoYXQgTkQgcGFja2V0cyBiZSBkcm9wcGVkIGlmIHRoZXkgYXJlIHJl Y2VpdmVkDQo+ID4gd2l0aCBhIFRUTCBvdGhlciB0aGFuIDI1NSAoaS5lLiwgdGhleSdkIHJlcXVp cmUgY2hvaWNlIGEpLiBJIHRoaW5rDQo+ID4gc29tZSBvdGhlciByb3V0aW5nIHByb3RvY29scyBk byB0aGUgc2FtZSAoYXMgYSB3YXkgdG8gaWdub3JlIHBhY2tldHMgZnJvbQ0KPiBvZmZsaW5rICJh dHRhY2tlcnMiKS4NCj4gDQo+IEhpIFRob21hcywNCj4gDQo+IEkgdGhpbmsgaXQncyB3b3J0aHdo aWxlIHRvIGRpc2N1c3MgdGhlIFRUTCBoYW5kbGluZyBpc3N1ZSBhc3NvY2lhdGVkIHdpdGggTDMN Cj4gc2VydmljZSBvciBMMyBvdmVybGF5LiBIb3dldmVyLCB0aGUgYWJvdmUgZXhhbXBsZSAoaS5l LiwgTkQpIGlzIG5vdCBhY2N1cmF0ZQ0KPiBzaW5jZSBpdCBzZWVtcyBubyBuZWVkIHRvIHRyYW5z cG9ydCB0aGUgTkQgbWVzc2FnZXMgYWNyb3NzIGEgTGF5ZXIzIG92ZXJsYXkuDQoNCkluIGFkZGl0 aW9uLCBJIGNhbid0IGltYWdpbmUgYSBzY2VuYXJpbyB3aGVyZSByb3V0aW5nIHByb3RvY29sIG1l c3NhZ2VzIG5lZWQgdG8gYmUgdHJhbnNwb3J0ZWQgYWNyb3NzIGEgTGF5ZXIzIG92ZXJsYXkgYXMg d2VsbCBpbiB0aGUgTlZPMyBjb250ZXh0Lg0KDQpYaWFvaHUNCg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IFhpYW9odQ0KPiANCj4gPiBXaGF0IGRvIHRlbmFudHMgb2YgYW4gTDMgc2VydmljZSBleHBlY3Q/ IERvIHRoZXkgY2FyZSAob3RoZXIgdGhhbiBpbg0KPiA+IGNhc2VzIGxpa2UgTkQpPw0KPiA+DQo+ ID4gQ2FuIHdlIGp1c3QgZGVmaW5lIEwzIHNlcnZpY2UgYXMgc2F5aW5nIHRoZSBUVEwgb2YgdGVu YW50IHBhY2tldHMgYXJlDQo+ID4gbm90IG1vZGlmaWVkIGJ5IE5WTzM/DQo+ID4NCj4gPiBBbnkg YWR2aWNlIGZyb20gTDMgc2VydmljZSBwcm92aWRlcnMgdGhhdCBhbHJlYWR5IHByb3ZpZGUgc3Vj aCBzZXJ2aWNlcw0KPiB0b2RheT8NCj4gPg0KPiA+IFRob21hcw0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBudm8zIG1haWxpbmcg bGlzdA0KPiA+IG52bzNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL252bzMNCg== From farinacci@gmail.com Tue Nov 26 18:08:51 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893541AE068 for ; Tue, 26 Nov 2013 18:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsHMp9pk2jYE for ; Tue, 26 Nov 2013 18:08:50 -0800 (PST) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 725921AE057 for ; Tue, 26 Nov 2013 18:08:50 -0800 (PST) Received: by mail-yh0-f43.google.com with SMTP id a41so4125948yho.30 for ; Tue, 26 Nov 2013 18:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MRqzjEg0GNHhBk9wrTnN4L4MVZ1SKmrdl4ypAY+zERs=; b=SxP0/lyC22uTsJC1ZebphEy0SgiOodRXQIkwUDKgJsuRC+wbRwAPae9DbqQPnUPwFl TgjHarkhVaH0vdOwQuXWNxwJ7AHNL3+Vgsy0/FFsPpMA0gYKI4QHI4SnC+7CxNJAt+lT fPp0T4vuh88LK2jUzEMHVmuRQi/tx3q7CgQltbBbKf6Dkz1DZrLVPAMwyaZ5ZMPHGLzw cgk+GtgHA4Z+MZRSbKuCOKdRbo4DXiMSGqHLAz3f68ZZwLs0ngMW8OhzrV4M1MjQRlSV /j1dEfwFvIxuyQgAgwztnHFHgSq7NABZjnHLYHHs4Zxs8Mce+kP/IT/lbhOvPSEJ3O/s 1tsw== X-Received: by 10.236.105.164 with SMTP id k24mr33580989yhg.30.1385518130054; Tue, 26 Nov 2013 18:08:50 -0800 (PST) Received: from ?IPv6:2602:306:37fe:1cc0:1d63:6141:cb0d:9923? ([2602:306:37fe:1cc0:1d63:6141:cb0d:9923]) by mx.google.com with ESMTPSA id r64sm25565593yhc.23.2013.11.26.18.08.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 18:08:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dino Farinacci X-Mailer: iPhone Mail (11B554a) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> Date: Tue, 26 Nov 2013 18:08:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5B1B06B0-C7F1-4ACC-AAF6-C6FF6AC9EB3A@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu Cc: Thomas Narten , Xuxiaohu , "nvo3@ietf.org" Subject: Re: [nvo3] =?utf-8?b?562U5aSNOiAgVFRMIGhhbmRsaW5nICBpbiBhbiBMMyBzZXJ2?= =?utf-8?q?ice?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 02:08:51 -0000 > In addition, I can't imagine a scenario where routing protocol messages ne= ed to be transported across a Layer3 overlay as well in the NVO3 context. I betcha many people would want to run multi-hop BGP on top of an overlay. := -) Dino= From xuxiaohu@huawei.com Tue Nov 26 18:21:12 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6C1AE078 for ; Tue, 26 Nov 2013 18:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW3ahSa9GwZz for ; Tue, 26 Nov 2013 18:21:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC901AE051 for ; Tue, 26 Nov 2013 18:21:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI79658; Wed, 27 Nov 2013 02:21:09 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 02:20:40 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 02:21:08 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 10:21:00 +0800 From: Xuxiaohu To: Dino Farinacci Thread-Topic: =?gb2312?B?W252bzNdILTwuLQ6ICBUVEwgaGFuZGxpbmcgIGluIGFuIEwzIHNlcnZpY2U=?= Thread-Index: AQHO6xWxPQbYtAQ430aATg/WcQso5Jo4Va+A Date: Wed, 27 Nov 2013 02:20:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082388B2@NKGEML512-MBS.china.huawei.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> <5B1B06B0-C7F1-4ACC-AAF6-C6FF6AC9EB3A@gmail.com> In-Reply-To: <5B1B06B0-C7F1-4ACC-AAF6-C6FF6AC9EB3A@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nvo3@ietf.org" Subject: [nvo3] =?gb2312?b?tPC4tDogILTwuLQ6ICBUVEwgaGFuZGxpbmcgIGluIGFu?= =?gb2312?b?IEwzIHNlcnZpY2U=?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 02:21:12 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMyBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBEaW5vIEZhcmluYWNjaQ0KPiC3osvNyrG85DogMjAxM8TqMTHU wjI3yNUgMTA6MDkNCj4gytW8/sjLOiBYdXhpYW9odQ0KPiCzrcvNOiBUaG9tYXMgTmFydGVuOyBY dXhpYW9odTsgbnZvM0BpZXRmLm9yZw0KPiDW98ziOiBSZTogW252bzNdILTwuLQ6IFRUTCBoYW5k bGluZyBpbiBhbiBMMyBzZXJ2aWNlDQo+IA0KPiA+IEluIGFkZGl0aW9uLCBJIGNhbid0IGltYWdp bmUgYSBzY2VuYXJpbyB3aGVyZSByb3V0aW5nIHByb3RvY29sIG1lc3NhZ2VzIG5lZWQNCj4gdG8g YmUgdHJhbnNwb3J0ZWQgYWNyb3NzIGEgTGF5ZXIzIG92ZXJsYXkgYXMgd2VsbCBpbiB0aGUgTlZP MyBjb250ZXh0Lg0KPiANCj4gSSBiZXRjaGEgbWFueSBwZW9wbGUgd291bGQgd2FudCB0byBydW4g bXVsdGktaG9wIEJHUCBvbiB0b3Agb2YgYW4gb3ZlcmxheS4gOi0pDQoNCklNSE8sIGl0IG1ha2Vz IHNlbnNlIHRvIHJ1biBCR1AgYW1vbmcgTlZFcy4gSW4gdGhpcyBjYXNlLCBCR1AgbWVzc2FnZXMg d291bGQgYmUgdHJhbnNwb3J0ZWQgb3ZlciB0aGUgdW5kZXJsYXksIHJhdGhlciB0aGFuIHRoZSBv dmVybGF5LiANCg0KPiBEaW5vDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From farinacci@gmail.com Tue Nov 26 19:54:20 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F331AE10D for ; Tue, 26 Nov 2013 19:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.95 X-Spam-Level: *** X-Spam-Status: No, score=3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i68J6NkEDzVn for ; Tue, 26 Nov 2013 19:54:19 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 375D61AE105 for ; Tue, 26 Nov 2013 19:54:19 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so9018469pde.41 for ; Tue, 26 Nov 2013 19:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/4uYp+jQ5ctaXLvOEJGKU3IpzO0oB0d92epovwY/yYE=; b=rlHEOjMxjJTanKsv3BjtqDpTo4LiNiEsuVSamzwf2gwheiCkEnAKWkHKmqoT3DOmPM u1BfJJhkrQQFF4GBeutDiExze407utht2Z8JrwCwvKgr5RhLEvs/qOtPrNoq0vtdbCOo NDCFI2LTxm3NgUBDdf26HU1qkr/LeHb5nDQnUkAdUwmabma4fJbjvvwPTNbiGG7MFp+G EgKECOYAQ2wiUsbhjgkhMPYTvGiZcw3jzifL0Ss0D9FvefoDJ2ObzXwO5LudM8ENarUY nejlj6ZqhktFP2JVXtwkP6t1G3aUc7mFA+8IMBC4a6Fw/8aT/oBsXdhrXDAHi4bL3DX7 KcJQ== X-Received: by 10.68.244.2 with SMTP id xc2mr2896202pbc.58.1385524458944; Tue, 26 Nov 2013 19:54:18 -0800 (PST) Received: from [192.168.1.13] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id ki1sm84367829pbd.1.2013.11.26.19.54.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 19:54:17 -0800 (PST) Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.0 $1822$) From: Dino Farinacci In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082388B2@NKGEML512-MBS.china.huawei.com> Date: Tue, 26 Nov 2013 19:54:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFE974D-7253-4D56-9F78-BA49A49E1423@gmail.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> <5B1B06B0-C7F1-4ACC-AAF6-C6FF6AC9EB3A@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082388B2@NKGEML512-MBS.china.huawei.com> To: Xuxiaohu X-Mailer: Apple Mail (2.1822) Cc: Thomas Narten , "nvo3@ietf.org" Subject: Re: [nvo3] =?gb2312?b?tPC4tDogIFRUTCBoYW5kbGluZyAgaW4gYW4gTDMgc2Vy?= =?gb2312?b?dmljZQ==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 03:54:20 -0000 > IMHO, it makes sense to run BGP among NVEs. In this case, BGP messages = would be transported over the underlay, rather than the overlay.=20 What if you wanted the BGP peer to be mobile? ;-) Dino From Garg.Pankaj@microsoft.com Tue Nov 26 21:19:46 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C781ABD2A for ; Tue, 26 Nov 2013 21:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.049 X-Spam-Level: **** X-Spam-Status: No, score=4.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4V-PSUQkjX5 for ; Tue, 26 Nov 2013 21:19:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 887551AE12C for ; Tue, 26 Nov 2013 21:19:44 -0800 (PST) Received: from BY2PR03MB128.namprd03.prod.outlook.com (10.242.36.28) by BY2PR03MB127.namprd03.prod.outlook.com (10.242.36.27) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 27 Nov 2013 05:19:42 +0000 Received: from BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.169]) by BY2PR03MB128.namprd03.prod.outlook.com ([169.254.5.105]) with mapi id 15.00.0820.005; Wed, 27 Nov 2013 05:19:41 +0000 From: Pankaj Garg To: Dino Farinacci , Xuxiaohu Thread-Topic: =?gb2312?B?W252bzNdILTwuLQ6ICBUVEwgaGFuZGxpbmcgIGluIGFuIEwzIHNlcnZpY2U=?= Thread-Index: AQHO6yRfy3DgfNL6JUGE77OyzGG3kJo4h7yA Date: Wed, 27 Nov 2013 05:19:41 +0000 Message-ID: References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08238877@NKGEML512-MBS.china.huawei.com> <5B1B06B0-C7F1-4ACC-AAF6-C6FF6AC9EB3A@gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082388B2@NKGEML512-MBS.china.huawei.com> <8AFE974D-7253-4D56-9F78-BA49A49E1423@gmail.com> In-Reply-To: <8AFE974D-7253-4D56-9F78-BA49A49E1423@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:7020:1020:1d2b:6fc2:d128:cf8e] x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(189002)(199002)(13464003)(377454003)(81816001)(4396001)(81686001)(15975445006)(49866001)(51856001)(47736001)(47976001)(74706001)(33646001)(80976001)(74316001)(50986001)(77982001)(19580405001)(19580395003)(83322001)(54356001)(53806001)(87936001)(83072001)(59766001)(56776001)(74876001)(85306002)(224303002)(69226001)(76786001)(74366001)(80022001)(74502001)(81542001)(65816001)(76576001)(31966008)(56816003)(74662001)(81342001)(77096001)(47446002)(2656002)(46102001)(76482001)(54316002)(87266001)(79102001)(76796001)(63696002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB127; H:BY2PR03MB128.namprd03.prod.outlook.com; CLIP:2001:4898:7020:1020:1d2b:6fc2:d128:cf8e; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Thomas Narten , "nvo3@ietf.org" Subject: Re: [nvo3] =?gb2312?b?tPC4tDogIFRUTCBoYW5kbGluZyAgaW4gYW4gTDMgc2Vy?= =?gb2312?b?dmljZQ==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 05:19:46 -0000 VGhlIG92ZXJsYXkgbmV0d29ya3Mgc2hvdWxkIGJlaGF2ZSBleGFjdGx5IGFzIHRoZSB1bmRlcmxh eSBuZXR3b3JrIChpbiB0ZXJtcyBvZiBiZWhhdmlvcikuIEkgdGhpbmssIGEgVFMgKG9yIFZNKSBy dW5uaW5nIG9uIG92ZXJsYXkgbmV0d29yayBzaG91bGRuJ3Qga25vdyB3aGV0aGVyIGl0IGlzIHJ1 bm5pbmcgb24gdG9wIG9mIHNvbWUgb3ZlcmxheSBvciBub3QuIEluIHN1Y2ggYSBuZXR3b3JrLCBp ZiB0aGUgdGVuYW50IGJyaW5ncyB0aGVpciBvd24gdmlydHVhbCBhcHBsaWFuY2UocykgdG8gY29u bmVjdCBtdWx0aXBsZSBWTnMgKHdoZXJlIGVhY2ggVk4gaXMgYW4gTDIgbmV0d29yayksIHRoZXkg c2hvdWxkIGJlIGFibGUgdG8gZXhjaGFuZ2UgQkdQIG9yIG90aGVyIHJvdXRpbmcgcHJvdG9jb2wg bWVzc2FnZXMgYW1vbmcgdGhvc2Ugcm91dGVycy4gU2ltaWxhcmx5LCBpZiBOVkUgaXMgZG9pbmcg dGhlIEwzIHJvdXRpbmcgYW5kIGNvbm5lY3RpbmcgbXVsdGlwbGUgTDIgVk5zLCBpdCBzaG91bGQg YmUgYWJsZSB0byBwZWVyIHdpdGggYSB0ZW5hbnQgb3duZWQgcm91dGVyLiBBIHNpbXBsZSB1c2Ug Y2FzZSBpcyBhIGdyb3VwIG9mIFZOcyBjb25uZWN0ZWQgdmlhIGFuIEwzIHJvdXRlciBhbmQgY29u bmVjdGVkIHZpYSBWUE4gb3Igb3RoZXIgc2VydmljZSB0byBvbi1wcmVtIG5ldHdvcmsuIEluIHRo aXMgY2FzZSwgaWYgdGhlIHJvdXRlIGNoYW5nZXMgaGFwcGVuIG9uIHRoZSBvbi1wcmVtIG5ldHdv cmssIHVzaW5nIEJHUCBvciBvdGhlciByb3V0aW5nIHByb3RvY29sIHRvIHByb3BhZ2F0ZSB0aGUg Y2hhbmdlcyB0byB0aGUgTDMgcm91dGVyIG9uIHRoZSBjbG91ZCBzaWRlIHdvdWxkIGJlIG5lZWRl ZC4NCg0KT24gVFRMLCBpZiB3ZSB0aGluayBvZiBOVkUgYXMgYSBzaW5nbGUgbG9naWNhbCByb3V0 ZXIsIHRoZW4gYXMgdGhlIHRyYWZmaWMgaXMgZm9yd2FyZGVkIGJldHdlZW4gb25lIEwyIFZOIHRv IGFub3RoZXIgTDIgVk4sIHRoZSBUVEwgc2hvdWxkIGRlY3JlbWVudCBieSAxLiBUaGUgYmVoYXZp b3Igd291bGQgYmUgZXhhY3RseSB0aGUgc2FtZSwgaWYgdGhlc2UgdHdvIFZOcyB3ZXJlIG5vdCB2 aXJ0dWFsIGFuZCBjb25uZWN0ZWQgdmlhIGEgcGh5c2ljYWwgcm91dGVyLiBUaGUgYmVoYXZpb3Ig d291bGQgYWxzbyBiZSB0aGUgc2FtZSBpZiB0aGVzZSB0d28gVk5zIHdlcmUgdmlydHVhbCBidXQg Y29ubmVjdGVkIHZpYSBhIHZpcnR1YWwgcm91dGVyIHJ1bm5pbmcgaW4gYSBWTS4gVGhpcyBnaXZl cyBjb25zaXN0ZW50IGJlaGF2aW9yIHRvIFRTIGluIGFsbCBjYXNlcyBpbmRlcGVuZGVudCBvZiB3 aGVyZSB0aGUgcm91dGVyIGlzIHJ1bm5pbmcgKG9yIGxvY2F0ZWQpLg0KDQpQYW5rYWoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGlubyBGYXJpbmFjY2kNCj4gU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAyNywgMjAxMyA5OjI0IEFNDQo+IFRvOiBYdXhpYW9odQ0KPiBDYzogVGhv bWFzIE5hcnRlbjsgbnZvM0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW252bzNdILTwuLQ6IFRU TCBoYW5kbGluZyBpbiBhbiBMMyBzZXJ2aWNlDQo+IA0KPiA+IElNSE8sIGl0IG1ha2VzIHNlbnNl IHRvIHJ1biBCR1AgYW1vbmcgTlZFcy4gSW4gdGhpcyBjYXNlLCBCR1AgbWVzc2FnZXMNCj4gd291 bGQgYmUgdHJhbnNwb3J0ZWQgb3ZlciB0aGUgdW5kZXJsYXksIHJhdGhlciB0aGFuIHRoZSBvdmVy bGF5Lg0KPiANCj4gV2hhdCBpZiB5b3Ugd2FudGVkIHRoZSBCR1AgcGVlciB0byBiZSBtb2JpbGU/ ICA7LSkNCj4gDQo+IERpbm8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IG52bzMgbWFpbGluZyBsaXN0DQo+IG52bzNAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From marc.lasserre@alcatel-lucent.com Wed Nov 27 03:09:41 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1F21AE283 for ; Wed, 27 Nov 2013 03:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSO5pdwNZA6S for ; Wed, 27 Nov 2013 03:09:38 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id C251D1AE27E for ; Wed, 27 Nov 2013 03:06:13 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rARB6705012586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Nov 2013 05:06:08 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rARB65lT019909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 12:06:06 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 27 Nov 2013 12:06:06 +0100 From: "LASSERRE, MARC (MARC)" To: Thomas Narten , Dino Farinacci Thread-Topic: [nvo3] TTL handling in an L3 service Thread-Index: AQHO6t/McPPVgcm3B0KZbvu3qdHqZJo46qdg Date: Wed, 27 Nov 2013 11:06:05 +0000 Message-ID: References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> In-Reply-To: <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "nvo3@ietf.org" Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 11:09:41 -0000 TTL processing in the context of nvo3 is already described in the draft-iet= f-nvo3-dataplane-requirements. See section 3.2.2 for details. Marc=20 > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Thomas Narten > Sent: Tuesday, November 26, 2013 8:43 PM > To: Dino Farinacci > Cc: nvo3@ietf.org > Subject: Re: [nvo3] TTL handling in an L3 service >=20 > Hi Dino. >=20 > I'm not really asking about TTL processing for tunnels in=20 > general... I'm asking specifically in the context of virtual=20 > network service, where tenants are connecting to virtual=20 > networks expecting either L2 or L3 service. What expectations=20 > to the TSes have when it comes to TTL modification? >=20 > In the L2 case, tenatnts expect to be given service equivalent to an > L2 broadcast domain. I.e., nodes can talk directly to each=20 > other at the L2 level using unicast/multicast. This is what=20 > we usually think of as being attached to a shared "link". >=20 > But what if the service being provided is L3? In this case=20 > TSes are only sending IP packets, but all TSes are directly=20 > reachable (i.e., without leaving the VN). What expectation do=20 > TSes in this type of situation expect of the TTL processing? >=20 > Do they even care? >=20 > Thomas >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > = From xuxiaohu@huawei.com Sat Nov 30 01:08:23 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A640C1AE282 for ; Sat, 30 Nov 2013 01:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgfO-rnSx4XY for ; Sat, 30 Nov 2013 01:08:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACFD1A8026 for ; Sat, 30 Nov 2013 01:08:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAW19541; Sat, 30 Nov 2013 09:08:17 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Nov 2013 09:07:34 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Nov 2013 09:08:13 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 30 Nov 2013 17:08:07 +0800 From: Xuxiaohu To: Dino Farinacci , Thomas Narten Thread-Topic: [nvo3] TTL handling in an L3 service Thread-Index: AQHO6t/F1KK4SWeRyU2SCyuEQd93Lpo3hbcAgAXg6WA= Date: Sat, 30 Nov 2013 09:08:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0823999F@NKGEML512-MBS.china.huawei.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> <672801AB-6968-4529-A45A-612B6B60B55B@gmail.com> <201311261943.rAQJh8HI016985@cichlid.raleigh.ibm.com> <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> In-Reply-To: <81D06AFC-A071-44BC-B344-2643FFA864CE@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nvo3@ietf.org" Subject: Re: [nvo3] TTL handling in an L3 service X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 09:08:23 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMyBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBEaW5vIEZhcmluYWNjaQ0KPiC3osvNyrG85DogMjAxM8TqMTHU wjI3yNUgNTo0NQ0KPiDK1bz+yMs6IFRob21hcyBOYXJ0ZW4NCj4gs63LzTogbnZvM0BpZXRmLm9y Zw0KPiDW98ziOiBSZTogW252bzNdIFRUTCBoYW5kbGluZyBpbiBhbiBMMyBzZXJ2aWNlDQo+IA0K PiA+IEhpIERpbm8uDQo+ID4NCj4gPiBJJ20gbm90IHJlYWxseSBhc2tpbmcgYWJvdXQgVFRMIHBy b2Nlc3NpbmcgZm9yIHR1bm5lbHMgaW4gZ2VuZXJhbC4uLg0KPiA+IEknbSBhc2tpbmcgc3BlY2lm aWNhbGx5IGluIHRoZSBjb250ZXh0IG9mIHZpcnR1YWwgbmV0d29yayBzZXJ2aWNlLA0KPiA+IHdo ZXJlIHRlbmFudHMgYXJlIGNvbm5lY3RpbmcgdG8gdmlydHVhbCBuZXR3b3JrcyBleHBlY3Rpbmcg ZWl0aGVyIEwyDQo+ID4gb3IgTDMgc2VydmljZS4gV2hhdCBleHBlY3RhdGlvbnMgIHRvIHRoZSBU U2VzIGhhdmUgIHdoZW4gaXQgY29tZXMgdG8NCj4gPiBUVEwgbW9kaWZpY2F0aW9uPw0KPiANCj4g SSB0aGluayBpdCBpcyBleGFjdGx5IHRoZSBzYW1lIGNhc2UuDQo+IA0KPiA+IEluIHRoZSBMMiBj YXNlLCB0ZW5hdG50cyBleHBlY3QgdG8gYmUgZ2l2ZW4gc2VydmljZSBlcXVpdmFsZW50IHRvIGFu DQo+ID4gTDIgYnJvYWRjYXN0IGRvbWFpbi4gSS5lLiwgbm9kZXMgY2FuIHRhbGsgZGlyZWN0bHkg dG8gZWFjaCBvdGhlciBhdA0KPiA+IHRoZSBMMiBsZXZlbCB1c2luZyB1bmljYXN0L211bHRpY2Fz dC4gVGhpcyBpcyB3aGF0IHdlIHVzdWFsbHkgdGhpbmsgb2YNCj4gPiBhcyBiZWluZyBhdHRhY2hl ZCB0byBhIHNoYXJlZCAibGluayIuDQo+IA0KPiBSaWdodCAtIGJ1dCBmb3IgYSBMMiBzZXJ2aWNl IHRoZXJlIGlzIG5vIFRUTCB0byBkZWNyZW1lbnQgaW4gdGhlIE5WRSBzaW5jZSBpdA0KPiBmb3J3 YXJkcyBhIHBhY2tldCBiYXNlZCBvbiBhIE1BQyBoZWFkZXIuDQo+IA0KPiA+IEJ1dCB3aGF0IGlm IHRoZSBzZXJ2aWNlIGJlaW5nIHByb3ZpZGVkIGlzIEwzPyBJbiB0aGlzIGNhc2UgVFNlcyBhcmUN Cj4gPiBvbmx5IHNlbmRpbmcgSVAgcGFja2V0cywgYnV0IGFsbCBUU2VzIGFyZSBkaXJlY3RseSBy ZWFjaGFibGUgKGkuZS4sDQo+ID4gd2l0aG91dCBsZWF2aW5nIHRoZSBWTikuIFdoYXQgZXhwZWN0 YXRpb24gZG8gVFNlcyBpbiB0aGlzIHR5cGUgb2YNCj4gPiBzaXR1YXRpb24gZXhwZWN0IG9mIHRo ZSBUVEwgcHJvY2Vzc2luZz8NCj4gDQo+ICJEaXJlY3RseSIgbmVlZHMgdG8gYmUgZGVmaW5lZCBh Ym92ZS4gSWYgdGhlIHR3byBUU2VzIGFyZSBpbiB0aGUgc2FtZSBzdWJuZXQNCj4gdGhlbiBpdCB3 b3VsZCBiZWhhdmUgYXMgaXQgZG9lcyB0b2RheSAod2hlbiAyIGhvc3RzIGFyZSBjb25uZWN0ZWQg dG8gaHViIC0gSQ0KPiBkb24ndCBzYXkgc3dpdGNoIGJlY2F1c2UgSSBkb24ndCB3YW50IHRvIGNv bXBsaWNhdGUgdGhlIGRpc2N1c3Npb24pLg0KPiANCj4gPiBEbyB0aGV5IGV2ZW4gY2FyZT8NCg0K PiBJZiBJIGFtIDEwLjAuMC4xIGluIENBIG9uIHN1Ym5ldCAxMC4wLjAuMC84IGFuZCB5b3UgYXJl IDEwLjAuMC4yIGluIE5ZIG9uIHN1Ym5ldA0KPiAxMC4wLjAuMC84IGFuZCB3ZSBhcmUgcmVhY2hh YmxlIHZpYSB0aGUgb3ZlcmxheSwgSSBleHBlY3Qgb25lIGxpbmUgaWYgb3V0cHV0IGZyb20NCj4g dHJhY2Vyb3V0ZS4gSWYgeW91IGFyZSAxMS4wLjAuMSBJIGV4cGVjdCBhdCBsZWFzdCAyIGxpbmVz IG9mIG91dHB1dC4NCg0KVGhvbWFzIGhhcyBhc2tlZCBhIHZlcnkgd29ydGh3aGlsZSBxdWVzdGlv bjogRG8gdGhleSBldmVuIGNhcmU/IA0KDQpBY2NvcmRpbmcgdG8gdGhlIFRUTCBoYW5kbGluZyBy ZXF1aXJlbWVudCBmb3IgTDMgVk5JIGFzIHNwZWNpZmllZCBpbiB0aGUgTlZvMyBEUCBSZXF1aXJl bWVudCBkb2MgKHNlZSBiZWxvdyksIGlmIHlvdSBkbyBhIHRyYWNlIHJvdXRlIGZvciAxMS4wLjAu MSwgdGhlIHRyYWNlIHJvdXRlIG91dHB1dCB3b3VsZCBiZSBleGFjdGx5IHRoZSBzYW1lIGFzIHlv dXIgZXhwZWN0YXRpb24gc2luY2UgTDMgTlZFcyBhcmUgdXN1YWxseSBhY3RpbmcgYXMgZGVmYXVs dCBHV3MuIFRoYXQncyB0byBzYXksIHlvdSBjYW4ndCBzZWUgYW55IGRpZmZlcmVuY2Ugd2hlbiB5 b3UgZG8gYSB0cmFjZSByb3V0ZSBmb3IgYW4gSVAgYWRkcmVzcyBvdXRzaWRlIHlvdXIgc3VibmV0 LiBJZiB5b3UgZG8gYSB0cmFjZSByb3V0ZSBmb3IgMTAuMC4wLjIsIHRoZSB0cmFjZSByb3V0ZSBv dXRwdXQgbWF5IGxpc3Qgb25lIG9yIHR3byBtb3JlIGhvcHMgKGkuZS4sIHRoZSBpbmdyZXNzIGFu ZC9vciB0aGUgZWdyZXNzIE5WRSkgdGhhbiB5b3VyIGFib3ZlIGV4cGVjdGF0aW9uLiBIb3dldmVy LCBkbyB5b3UgcmVhbGx5IGNhcmUgYWJvdXQgdGhlIHRyYWNlIHJvdXRlIG91dHB1dCBmb3IgYW4g SVAgYWRkcmVzcyB3aGljaCBpcyB3aXRoaW4gdGhlIHNhbWUgc3VibmV0IGFzIHlvdXJzPyBXaGF0 J3MgeW91ciBzcGVjaWFsIHB1cnBvc2UgZm9yIGRvaW5nIGEgdHJhY2Ugcm91dGUsIHJhdGhlciB0 aGFuIGEgUElORyBmb3IgYW4gSVAgYWRkcmVzcyB3aGljaCBiZWxvbmdzIHRvIHRoZSBzYW1lIHN1 Ym5ldCBhcyB5b3Vycz8gDQoNClRvIHNvbWUgZXh0ZW50LCB0aGUgTDMgZm9yd2FyZGluZyBmb3Ig aW50cmEtc3VibmV0IHRyYWZmaWMgaXMganVzdCBhIHNwZWNpYWwgdXNlIGNhc2Ugb2YgdGhlIFBy b3h5IEFSUCBtZWNoYW5pc20gW1JGQzEwMjddLiBUaGF0J3MgdG8gc2F5LCB0aGUgdHJhZmZpYyBm cm9tIDEwLjAuMC4xIHRvIDEwLjAuMC4yIGlzIGludHJhLXN1Ym5ldCB0cmFmZmljIGZyb20gdGhl IGhvc3QncyBQT1Ygd2hpbGUgaXQgaXMgYWxzbyBpbnRlci1zdWJuZXQgdHJhZmZpYyBmcm9tIHRo ZSByb3V0ZXIncyBQT1YuIFRoZXJlZm9yZSwgdGhlIGFib3ZlICJ1bmV4cGVjdGVkIiB0cmFjZSBy b3V0ZSBvdXRwdXQgZGVtb25zdHJhdGVzIGV4YWN0bHkgdGhlIHJvdXRlciBob3BzIHRoYXQgdGhl IGludHJhLXN1Ym5ldCB0cmFmZmljIChmcm9tIHRoZSB0ZW5hbnQgaG9zdCBQT1YpIHdvdWxkIHRy YXZlcnNlIG9uIHRoZSBvdmVybGF5IHBhdGguIA0KDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqDQozLjIuMi4gTDMgVk5JDQogICAgDQogICAgICAgTDMgVk5JcyBNVVNUIHByb3ZpZGUg dmlydHVhbGl6ZWQgSVAgcm91dGluZyBhbmQgZm9yd2FyZGluZy4gTDMgVk5Jcw0KICAgICAgIE1V U1Qgc3VwcG9ydCBwZXItdGVuYW50IGZvcndhcmRpbmcgaW5zdGFuY2Ugd2l0aCBJUCBhZGRyZXNz aW5nDQogICAgICAgaXNvbGF0aW9uIGFuZCBMMyB0dW5uZWxpbmcgZm9yIGludGVyY29ubmVjdGlu ZyBpbnN0YW5jZXMgb2YgdGhlIHNhbWUNCiAgICAgICBWTkkgb24gTlZFcy4NCiAgICANCiAgICAg ICBJbiB0aGUgY2FzZSBvZiBMMyBWTkksIHRoZSBpbm5lciBUVEwgZmllbGQgTVVTVCBiZSBkZWNy ZW1lbnRlZCBieQ0KICAgICAgIChhdCBsZWFzdCkgMSBhcyBpZiB0aGUgTlZPMyBlZ3Jlc3MgTlZF IHdhcyBvbmUgKG9yIG1vcmUpIGhvcChzKQ0KICAgICAgIGF3YXkuIFRoZSBUVEwgZmllbGQgaW4g dGhlIG91dGVyIElQIGhlYWRlciBNVVNUIGJlIHNldCB0byBhIHZhbHVlDQogICAgDQogICAgDQog ICAgTGFzc2VycmUsIGV0IGFsLiAgICAgICAgRXhwaXJlcyBNYXkgMTIsIDIwMTQgICAgICAgICAg ICAgICAgICBbUGFnZSA2XQ0KICAgICANCiAgICBJbnRlcm5ldC1EcmFmdCAgICAgICAgTlZPMyBE YXRhIFBsYW5lIFJlcXVpcmVtZW50cyAgICAgICAgTm92ZW1iZXIgMjAxMw0KICAgIA0KICAgIA0K ICAgICAgIGFwcHJvcHJpYXRlIGZvciBkZWxpdmVyeSBvZiB0aGUgZW5jYXBzdWxhdGVkIGZyYW1l IHRvIHRoZSB0dW5uZWwNCiAgICAgICBleGl0IHBvaW50LiBUaHVzLCB0aGUgZGVmYXVsdCBiZWhh dmlvciBNVVNUIGJlIHRoZSBUVEwgcGlwZSBtb2RlbA0KICAgICAgIHdoZXJlIHRoZSBvdmVybGF5 IG5ldHdvcmsgbG9va3MgbGlrZSBvbmUgaG9wIHRvIHRoZSBzZW5kaW5nIE5WRS4NCiAgICAgICBD b25maWd1cmF0aW9uIG9mIGEgInVuaWZvcm0iIFRUTCBtb2RlbCB3aGVyZSB0aGUgb3V0ZXIgdHVu bmVsIFRUTCBpcw0KICAgICAgIHNldCBlcXVhbCB0byB0aGUgaW5uZXIgVFRMIG9uIGluZ3Jlc3Mg TlZFIGFuZCB0aGUgaW5uZXIgVFRMIGlzIHNldA0KICAgICAgIHRvIHRoZSBvdXRlciBUVEwgdmFs dWUgb24gZWdyZXNzIE1BWSBiZSBzdXBwb3J0ZWQuDQoqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBEaW5vDQo+IA0KPiA+DQo+ID4g VGhvbWFzDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From xuxiaohu@huawei.com Sat Nov 30 01:54:32 2013 Return-Path: X-Original-To: nvo3@ietfa.amsl.com Delivered-To: nvo3@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5F41AE140 for ; Sat, 30 Nov 2013 01:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.087 X-Spam-Level: ** X-Spam-Status: No, score=2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi63a9JoDUZO for ; Sat, 30 Nov 2013 01:54:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C85A81AE3EE for ; Sat, 30 Nov 2013 01:54:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYM14674; Sat, 30 Nov 2013 09:54:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Nov 2013 09:53:46 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Nov 2013 09:54:25 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.45]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Sat, 30 Nov 2013 17:54:20 +0800 From: Xuxiaohu To: Thomas Narten , "nvo3@ietf.org" Thread-Topic: [nvo3] TTL handling in an L3 service Thread-Index: AQHO6sizzAw8KGV/Hk62HkBEakS2Lpo9h+0w Date: Sat, 30 Nov 2013 09:54:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082399D3@NKGEML512-MBS.china.huawei.com> References: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> In-Reply-To: <201311261657.rAQGvwtR023978@cichlid.raleigh.ibm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nvo3] =?gb2312?b?tPC4tDogIFRUTCBoYW5kbGluZyAgaW4gYW4gTDMgc2Vy?= =?gb2312?b?dmljZQ==?= X-BeenThere: nvo3@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Network Virtualization Overlays $NVO3$ Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 09:54:32 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbnZvMyBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBUaG9tYXMgTmFydGVuDQo+ILeiy83KsbzkOiAyMDEzxOoxMdTC MjfI1SAwOjU4DQo+IMrVvP7IyzogbnZvM0BpZXRmLm9yZw0KPiDW98ziOiBbbnZvM10gVFRMIGhh bmRsaW5nIGluIGFuIEwzIHNlcnZpY2UNCj4gDQo+IEhpLg0KPiANCj4gSW4gcHJlY2lzZWx5IGRl ZmluaW5nIEwzIHNlcnZpY2UsIG9uZSBxdWVzdGlvbiB0aGF0IGNvbWVzIHVwIGlzIGhvdyBpcyB0 aGUgVFRMDQo+IHRyZWF0ZWQuIFRoYXQgaXMsIHNheSBOVk8zIHByb3ZpZGVzIEwzIFZOIHNlcnZp Y2UgdG8gYSBUUy4gV2hlbiBUU2VzIG9uIHRoZSBWTg0KPiBjb21tdW5pY2F0ZSB3aXRoIGVhY2gg b3RoZXIsIHRoZXkgYXJlIGFsd2F5cyB1c2luZyBJUC4gV2hhdCBoYXBwZW5zIHRvIHRoZQ0KPiBU VEwgaW4gc3VjaCBwYWNrZXRzPw0KPiANCj4gSSBzZWUgc2V2ZXJhbCBjaG9pY2VzOg0KPiANCj4g YSkgZG8gbm90IGRlY3JlbWVudCB0aGUgVFRMIGF0IGFsbC4gVHJlYXQgdGhlIFRTZXMgYXMgaWYg dGhleSB3ZXJlIGRpcmVjdGx5DQo+ICAgIGF0dGFjaGVkIHRvIGVhY2ggb3RoZXIgKGkuZS4sIG9u IHRoZSBzYW1lIGxpbmspDQo+IA0KPiBiKSBEZWNyZW1lbnQgYnkgMS4uLg0KPiANCj4gYykgRGVj cmVtZW50IGJ5IHNvbWUgcmFuZG9tIGFtb3VudC4uIDotKQ0KPiANCj4gU29tZSBwcm90b2NvbHMg bWF5IGNhcmUgYWJvdXQgVFRMIGhhbmRsaW5nLiBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSwgZm9y DQo+IGV4YW1wbGUsIHJlcXVpcmVzIHRoYXQgTkQgcGFja2V0cyBiZSBkcm9wcGVkIGlmIHRoZXkg YXJlIHJlY2VpdmVkIHdpdGggYSBUVEwNCj4gb3RoZXIgdGhhbiAyNTUgKGkuZS4sIHRoZXknZCBy ZXF1aXJlIGNob2ljZSBhKS4gSSB0aGluayBzb21lIG90aGVyIHJvdXRpbmcNCj4gcHJvdG9jb2xz IGRvIHRoZSBzYW1lIChhcyBhIHdheSB0byBpZ25vcmUgcGFja2V0cyBmcm9tIG9mZmxpbmsgImF0 dGFja2VycyIpLg0KPiANCj4gV2hhdCBkbyB0ZW5hbnRzIG9mIGFuIEwzIHNlcnZpY2UgZXhwZWN0 PyBEbyB0aGV5IGNhcmUgKG90aGVyIHRoYW4gaW4gY2FzZXMgbGlrZQ0KPiBORCk/DQo+IA0KPiBD YW4gd2UganVzdCBkZWZpbmUgTDMgc2VydmljZSBhcyBzYXlpbmcgdGhlIFRUTCBvZiB0ZW5hbnQg cGFja2V0cyBhcmUgbm90DQo+IG1vZGlmaWVkIGJ5IE5WTzM/DQo+IA0KPiBBbnkgYWR2aWNlIGZy b20gTDMgc2VydmljZSBwcm92aWRlcnMgdGhhdCBhbHJlYWR5IHByb3ZpZGUgc3VjaCBzZXJ2aWNl cyB0b2RheT8NCg0KSGkgVGhvbWFzLA0KDQpCeSB0aGUgd2F5LCB5b3UgbWF5IGFsc28gYXNrIGZl ZWRiYWNrcyBmcm9tIHNvbWUgdmVuZG9ycyB3aG8gaGF2ZSBpbXBsZW1lbnRlZCB0aGUgZmVhdHVy ZSBvZiBmb3J3YXJkaW5nIGludHJhLXN1Ym5ldCB0cmFmZmljIGF0IEwzIGluIHRoZWlyIHJlbGVh c2VkIGRhdGEgY2VudGVyIG5ldHdvcmsgcHJvZHVjdHMuDQoNCkZyb20gdGhlIGZvbGxvd2luZyBw dWJsaWMgaW5mb3JtYXRpb24gd2hpY2ggY2FuIGJlIGdvb2dsZWQsIGl0IHNlZW1zIGF0IGxlYXN0 IHRoZSBmb2xsb3dpbmcgdGhyZWUgdmVuZG9ycyBoYXZlIGltcGxlbWVudGVkIGl0Og0KDQp3d3cu anVuaXBlci5uZXQvdXMvZW4vbG9jYWwvcGRmL3doaXRlcGFwZXJzLzIwMDA1MzUtZW4ucGRmDQoo cXVvdGVkIHRleHQ6IEZhbGxiYWNrIFN3aXRjaGluZw0KQ29udHJhaWwgc3VwcG9ydHMgYSBoeWJy aWQgbW9kZSB3aGVyZSBhIHZpcnR1YWwgbmV0d29yayBpcyBib3RoIGEgTDIgYW5kIGEgTDMgb3Zl cmxheSBzaW11bHRhbmVvdXNseS4gSW4gdGhpcyBjYXNlIHRoZQ0Kcm91dGluZyBpbnN0YW5jZXMg b24gdGhlIHZSb3V0ZXJzIGhhdmUgYm90aCBhbiBJUCBGSUIgYW5kIGEgTUFDIEZJQi4gRm9yIGV2 ZXJ5IHBhY2tldCwgdGhlIHZSb3V0ZXIgZmlyc3QgZG9lcyBhIGxvb2t1cA0KaW4gdGhlIElQIEZJ Qi4gSWYgdGhlIElQIEZJQiBjb250YWlucyBhIG1hdGNoaW5nIHJvdXRlLCBpdCBpcyB1c2VkIGZv ciBmb3J3YXJkaW5nIHRoZSBwYWNrZXQuIElmIHRoZSBJUCBGSUIgZG9lcyBub3QgY29udGFpbiBh DQptYXRjaGluZyByb3V0ZSwgdGhlIHZSb3V0ZXIgZG9lcyBhIGxvb2t1cCBpbiB0aGUgTUFDIEZJ QqGqaGVuY2UgdGhlIG5hbWUgZmFsbGJhY2sgc3dpdGNoaW5nLg0KTm90ZSB0aGF0IHRoZSChsHJv dXRlIGZpcnN0IGFuZCB0aGVuIGJyaWRnZaGxIGJlaGF2aW9yIG9mIGZhbGxiYWNrIHN3aXRjaGlu ZyBpcyB0aGUgb3Bwb3NpdGUgb2YgdGhlIKGwYnJpZGdlIGZpcnN0IGFuZCB0aGVuDQpyb3V0ZaGx IGJlaGF2aW9yIG9mIGludGVncmF0ZWQgcm91dGluZyBhbmQgYnJpZGdpbmcgKElSQikuKQ0KDQpo dHRwOi8vYmxvZ3MuZW50ZXJhc3lzLmNvbS9kY2ktbWFkZS1zaW1wbGUtd2l0aC1vbmVmYWJyaWMv DQoocXVvdGVkIHRleHQ6IEZhYnJpYyBSb3V0aW5nIHdpdGggSVAgbW9iaWxpdHkgdXNlcyBob3N0 IHJvdXRpbmcgdGVjaG5pcXVlcyB0byBkeW5hbWljYWxseSBkaXN0cmlidXRlIGFuZCBpbmplY3Qg aG9zdCByb3V0ZXMgZnJvbSB0aGUgZGF0YSBjZW50ZXIgc3dpdGNoICh0aGF0IGhhcyBmYWJyaWMg cm91dGluZyBlbmFibGVkKSB0aGF0IGEgVk0gaXMgY2xvc2VzdCBjb25uZWN0ZWQgdG8gqEMgYW5k IHJlbW92ZSB0aGVtIGZyb20gdGhlIHByZXZpb3VzIGNsb3Nlc3QgZmFicmljIHJvdXRpbmcgc3dp dGNoKQ0KDQpodHRwOi8vd3d3LmNpc2NvLmNvbS9lbi9VUy9zb2x1dGlvbnMvY29sbGF0ZXJhbC9u czIyNC9uczk0NS93aGl0ZV9wYXBlcl9jMTEtNzI4MzM3LnBkZg0KKHF1b3RlZCB0ZXh0OiBDaXNj byBERkEgYWR2YW5jZW1lbnRzIGluY2x1ZGUgZW5oYW5jZWQgZm9yd2FyZGluZywgaW4gd2hpY2gg SVAgYWRkcmVzc2VzIGFyZSB1c2VkIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUNCmNvbW11bmlj YXRpb24gaXMgd2l0aGluIG9yIGJldHdlZW4gdHJhZGl0aW9uYWwgTGF5ZXIgMiBzdWJuZXRzLiBU aGlzIGZlYXR1cmUgaW50cm9kdWNlcyBzZXZlcmFsIG9wdGltaXphdGlvbnMgYW5kDQpzaW1wbGlm aWNhdGlvbnMsIGluY2x1ZGluZyB0aGUgZWxpbWluYXRpb24gb2YgYSBmaXJzdC1ob3AgcmVkdW5k YW5jeSBwcm90b2NvbCwgdGhlIHVzZSBvZiBzbWFsbCBNQUMgYWRkcmVzcyB0YWJsZXMsDQphbmQg b3B0aW1hbCBmb3J3YXJkaW5nIGZvciBhbGwgdW5pY2FzdCBmcmFtZXMuKQ0KDQpodHRwOi8vd3d3 LnZhbGxleXRhbGsub3JnL3dwLWNvbnRlbnQvdXBsb2Fkcy8yMDEzLzA4L2Npc2NvREZBLnBkZg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KDQo+IFRob21hcw0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnZvMyBtYWlsaW5nIGxpc3QN Cj4gbnZvM0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L252bzMNCg==