Subject: [nvo3] FW: Call for interest on NVO3 use case draft

From: David Allan I <[email-masked]>
Date: Fri, 12 Aug 2016 23:16:32 +0000

Hi Matthew:

I’ve read the draft, and as much as I believe it is a useful piece of work, I think it misses the mark in a few cases. I believe if they were addressed, the utility of the document would be improved

IMO this is primarily in that certain technical requirements which in themselves could be considered use cases are presented without rationale…. This is primarily confined to section 4….

In 4.1 the ability to interconnect different technologies, fine… but then it diverges in discussing a tiered application and zone interconnection. Unrelated to the heterogeneous technology problem, and why I’d want interconnect between the web tier and the storage tier completely escapes me with or without a firewall… I’d recommend splitting these use cases, and providing either a different example of firewalled zone interconnect or a rationale for the example that elaborated a bit more on the motivations.

4.2 Why I would subnet my overlay could use some explanation. I normally think of subnetting as a  convenient address summarization technique dependent on topology, and with an overlay I don’t have a topology. So the reason for introducing the complexity should be explained rather than simply offering this as a feature. Is this requirement elaborated on in any other drafts….?

If I were to generalize where the use cases were going, I think the key themes are:

1)      Separation of tenants (and rationale, although somewhat obvious ☺)

2)      Rationale for multiple tenant networks vs. multiple zones in a single network and perhaps cases for both

e.g              Separation of zones within a tenant network for either technical or security reasons. Vs. hardwalling separate networks with no interconnect

3)      Partitioning of tenant networks on the basis of L2 and/or L3….and a rationale for same.

I think something along these lines would give the document a lot more structure and focus, and perhaps address some of the concerns vis-à-vis this as a standalone document vs. being folded into other documents.

My 2 cents
Dave

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2016 17:07:13 -0700

On 8/12/2016 4:16 PM, David Allan I wrote:
> 4.2 Why I would subnet my overlay could use some explanation. I
> normally think of subnetting as a  convenient address summarization
> technique dependent on topology, and with an overlay I don’t have a
> topology. 

The topology of an overlay is determined by its tunnels, just as the
topology of the underlying net is determined by its links.

A subnet in an overlay corresponds either to a single multipoint tunnel
or to a set of tunnels that transparently acts as such - just as a
subnet in the Internet base network corresponds to a shared access link
or a set of links that transparently act as such (e.g., switched ethernet).

Joe

---

From: David Allan I <[email-masked]>
Date: Sat, 13 Aug 2016 02:11:45 +0000

My point would be that introducing  additional complexity in an overlay should have a use case associate with it. It would not be something you would do gratuitously....

SO I'm looking for the draft to provide a use case for this vs. simply mentioning  subnetting without any context :)

Cheers
Dave

From: nvo3 [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Friday, August 12, 2016 5:07 PM
To: David Allan I <[email-masked]>; [email-masked]; Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Re: [nvo3] FW: Call for interest on NVO3 use case draft

On 8/12/2016 4:16 PM, David Allan I wrote:
4.2 Why I would subnet my overlay could use some explanation. I normally think of subnetting as a  convenient address summarization technique dependent on topology, and with an overlay I don't have a topology.

The topology of an overlay is determined by its tunnels, just as the topology of the underlying net is determined by its links.

A subnet in an overlay corresponds either to a single multipoint tunnel or to a set of tunnels that transparently acts as such - just as a subnet in the Internet base network corresponds to a shared access link or a set of links that transparently act as such (e.g., switched ethernet).

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 12 Aug 2016 20:20:18 -0700

The typical use case is to support subnet emulation, e.g., a group of links over which broadcast is emulated as with LANE. 

> On Aug 12, 2016, at 7:11 PM, David Allan I <[email-masked]> wrote:
> 
> My point would be that introducing  additional complexity in an overlay should have a use case associate with it. It would not be something you would do gratuitously….
>  
> SO I’m looking for the draft to provide a use case for this vs. simply mentioning  subnetting without any context J 
>  
> Cheers
> Dave
>  
> 4.2 Why I would subnet my overlay could use some explanation. I normally think of subnetting as a  convenient address summarization technique dependent on topology, and with an overlay I don’t have a topology.
>

---

From: David Allan I <[email-masked]>
Date: Sat, 13 Aug 2016 16:52:54 +0000

Hi Joe

And the use case for wanting to do subnet emulation is….?

That‘s my question
Dave

From: Joe Touch [mailto:[email-masked]]
Sent: Friday, August 12, 2016 8:20 PM
To: David Allan I <[email-masked]>
Cc: [email-masked]; Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Re: [nvo3] FW: Call for interest on NVO3 use case draft

On Aug 12, 2016, at 7:11 PM, David Allan I <[email-masked]<mailto:[email-masked]>> wrote:
My point would be that introducing  additional complexity in an overlay should have a use case associate with it. It would not be something you would do gratuitously….

SO I’m looking for the draft to provide a use case for this vs. simply mentioning  subnetting without any context ☺

Cheers
Dave

From: nvo3 [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Friday, August 12, 2016 5:07 PM
To: David Allan I <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] FW: Call for interest on NVO3 use case draft

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 13 Aug 2016 10:29:38 -0700

> And the use case for wanting to do subnet emulation is….? 

You want the properties of a subnet and/or to emulate the behavior of a
shared link, i.e., to limit the scope of various protocols, including IP
routing, IPv6 automatic addressing, L2 address translation (virtualizing
L2 underneath a virtual L3 is needed to support revisitation, where a
single node participates multiple times in an overlay), and basically
any subnet-based resource discovery.

Joe

>  
>
> That‘s my question
>
> Dave
>
>  
>
> *From:*Joe Touch [mailto:[email-masked]]
> *Sent:* Friday, August 12, 2016 8:20 PM
> *To:* David Allan I <[email-masked]>
> *Cc:* [email-masked]; Bocci, Matthew (Nokia - GB) <[email-masked]>
> *Subject:* Re: [nvo3] FW: Call for interest on NVO3 use case draft
>
>  
>
> The typical use case is to support subnet emulation, e.g., a group of
> links over which broadcast is emulated as with LANE. 
>
>
> On Aug 12, 2016, at 7:11 PM, David Allan I <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     My point would be that introducing  additional complexity in an
>     overlay should have a use case associate with it. It would not be
>     something you would do gratuitously….
>
>      
>
>     SO I’m looking for the draft to provide a use case for this vs.
>     simply mentioning  subnetting without any context J 
>
>      
>
>     Cheers
>
>     Dave
>
>      
>
>     *From:*nvo3 [mailto:[email-masked]] *On Behalf Of *Joe Touch
>     *Sent:* Friday, August 12, 2016 5:07 PM
>     *To:* David Allan I <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>; Bocci, Matthew (Nokia - GB)
>     <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [nvo3] FW: Call for interest on NVO3 use case draft
>
>      
>
>      
>
>      
>
>         4.2 Why I would subnet my overlay could use some explanation.
>         I normally think of subnetting as a  convenient address
>         summarization technique dependent on topology, and with an
>         overlay I don’t have a topology.
>
>
>     The topology of an overlay is determined by its tunnels, just as
>     the topology of the underlying net is determined by its links.
>
>     A subnet in an overlay corresponds either to a single multipoint
>     tunnel or to a set of tunnels that transparently acts as such -
>     just as a subnet in the Internet base network corresponds to a
>     shared access link or a set of links that transparently act as
>     such (e.g., switched ethernet).
>
>     Joe
>

---

From: "Reith, Lothar" <[email-masked]>
Date: Sat, 13 Aug 2016 23:20:05 +0000

Hi Joe, Dave, dear all,

I think that the term “subnet” is indeed only defined in a context sensitive way.

Unfortunately there is no distinction made between a L2-subnet (aka a broadcast domain, or a MEF EVC, or o broadcast domain equivalent achieved without broadcast such as EVPN) and a L3-subnet (the object that does not appear in any information  model that I am aware of, but which has a size which is defined by a subnet-mask and which supports the use case of “change the IP-address range assigned to that subnet”.

Part of the reason for complexity is the lack of a proper definition of this object in the information model.

If I am wrong – I would be happy to be corrected by someone who can point me to an authoritative definition of the term subnet as an object that supports the use case “change address range assigned to subnet” without specifying how the subnet is built as layer 2 construct (e.g. as Ethernet yellow cable, VLAN in a Switched Ethernet domain, VXLAN overlay, EVPN, MEF EVC or ATM point to point link).

Thanks to OpenStack for  finally fixing the problem by introducing the method “create network”, which creates – exactly – this missing object in an abstract way.

So Dave’s question is very valid, simply because the term “subnetting” is not properly defined – unless the authors point to a reference RFC where the term is defined in an authoritative way.

Lothar

Von: nvo3 [mailto:[email-masked]] Im Auftrag von Joe Touch
Gesendet: Samstag, 13. August 2016 19:30
An: David Allan I <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
Betreff: Re: [nvo3] FW: Call for interest on NVO3 use case draft

You want the properties of a subnet and/or to emulate the behavior of a shared link, i.e., to limit the scope of various protocols, including IP routing, IPv6 automatic addressing, L2 address translation (virtualizing L2 underneath a virtual L3 is needed to support revisitation, where a single node participates multiple times in an overlay), and basically any subnet-based resource discovery.

Joe

That‘s my question
Dave

From: Joe Touch [mailto:[email-masked]]
Sent: Friday, August 12, 2016 8:20 PM
To: David Allan I <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Bocci, Matthew (Nokia - GB) <[email-masked]><mailto:[email-masked]>
Subject: Re: [nvo3] FW: Call for interest on NVO3 use case draft

Cheers
Dave

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 13 Aug 2016 16:45:11 -0700

On 8/13/2016 4:20 PM, Reith, Lothar wrote:
> Unfortunately there is no distinction made between a L2-subnet (aka a
> broadcast domain, or a MEF EVC, or o broadcast domain equivalent
> achieved without broadcast such as EVPN) and a L3-subnet (the object
> that does not appear in any information  model that I am aware of, but
> which has a size which is defined by a subnet-mask and which supports
> the use case of “change the IP-address range assigned to that subnet”.
>
The reason that L2 broadcast domain and L3 subnet (as per RFC1812)
coincide is that is the basis of most L3:L2 mapping mechanisms, e.g.,
ARP (RFC826) or ARP emulation (RFC1577).

And the concept of an L3 subnet is pervasive in many RFCs, being the
basis of hierarchical IP forwarding since its inception. There's even a
specific RFC advising on the design of L2 subnets to support L3 subnets
(3819).

> If I am wrong – I would be happy to be corrected by someone who can
> point me to an authoritative definition of the term subnet as an
> object that supports the use case “change address range assigned to
> subnet” without specifying how the subnet is built as layer 2
> construct (e.g. as Ethernet yellow cable, VLAN in a Switched Ethernet
> domain, VXLAN overlay, EVPN, MEF EVC or ATM point to point link).
>

Subnet in L3 in IPv4 is defined as per RFC 4632

Subnet in L3 in IPv6 is defined as per RFC 4291

These are very old and fundamental concepts to the Internet
architecture. Any notion of virtualizing L3 needs to deal with them.

Joe

>  
>
> Thanks to OpenStack for  finally fixing the problem by introducing the
> method “create network”, which creates – exactly – this missing object
> in an abstract way.
>
>  
>
> So Dave’s question is very valid, simply because the term “subnetting”
> is not properly defined – unless the authors point to a reference RFC
> where the term is defined in an authoritative way.
>
>  
>
> Lothar
>
>  
>
>  
>
>  
>
> *Von:*nvo3 [mailto:[email-masked]] *Im Auftrag von *Joe Touch
> *Gesendet:* Samstag, 13. August 2016 19:30
> *An:* David Allan I <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
> *Betreff:* Re: [nvo3] FW: Call for interest on NVO3 use case draft
>
>  
>
>  
>
> You want the properties of a subnet and/or to emulate the behavior of
> a shared link, i.e., to limit the scope of various protocols,
> including IP routing, IPv6 automatic addressing, L2 address
> translation (virtualizing L2 underneath a virtual L3 is needed to
> support revisitation, where a single node participates multiple times
> in an overlay), and basically any subnet-based resource discovery.
>
> Joe
>
>
>      
>
>     That‘s my question
>
>     Dave
>
>      
>
>     <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Bocci, Matthew (Nokia
>     - GB) <[email-masked]> <mailto:[email-masked]>
>     The typical use case is to support subnet emulation, e.g., a group
>     of links over which broadcast is emulated as with LANE. 
>
>
>     On Aug 12, 2016, at 7:11 PM, David Allan I
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>         My point would be that introducing  additional complexity in
>         an overlay should have a use case associate with it. It would
>         not be something you would do gratuitously….
>
>          
>
>         SO I’m looking for the draft to provide a use case for this
>         vs. simply mentioning  subnetting without any context J 
>
>          
>
>         Cheers
>
>         Dave
>
>          
>
>             4.2 Why I would subnet my overlay could use some
>             explanation. I normally think of subnetting as a 
>             convenient address summarization technique dependent on
>             topology, and with an overlay I don’t have a topology.
>
>
>         The topology of an overlay is determined by its tunnels, just
>         as the topology of the underlying net is determined by its links.
>
>         A subnet in an overlay corresponds either to a single
>         multipoint tunnel or to a set of tunnels that transparently
>         acts as such - just as a subnet in the Internet base network
>         corresponds to a shared access link or a set of links that
>         transparently act as such (e.g., switched ethernet).
>
>         Joe
>
>  
>

---

From: David Allan I <[email-masked]>
Date: Mon, 15 Aug 2016 16:23:05 +0000

So long as we are running down this rabbit hole…. ☺

My very original comment was “if this is a use case document, why is this concept in here with no associated use case for why I would need it? Could we have a use case please”

As the comment referred to multiple subnets, I would then observe that as far as IP is concerned, a subnet traditionally corresponds to a broadcast domain. These days I do not necessarily need to implement it via traditional bridging, and a lot of traditional discovery is changing to being database driven configuration. But I would have no trouble noting that a broadcast domain that also corresponds to a subnet has useful properties at a bunch of levels as a subnet prefix/mask becomes a convenient shorthand for the set, although a VNI is an even more convenient shorthand ☺  But if I want to run a single network as if it were a subnet using established tools, fine….

What I am less clear on is constructing a virtual network of multiple subnets and creating a virtual topology when AFAIK this does not get me much. Am I simply scaling a single community of interest to which common policies apply? IN which case most of the properties a broadcast domain gets me, I’d want to see at L3.  Am I defining relationships between dissimilar communities of interest, which is wildly overloading the concept… As noted above policy could equally be expressed as VNI relationships, which likely is an equally useful abstraction.

I hope this is clear
Dave

Sent: Saturday, August 13, 2016 10:30 AM

Joe

That‘s my question
Dave

Cheers
Dave

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 09:35:13 -0700

Hi, David,

On 8/15/2016 9:23 AM, David Allan I wrote:
>
> So long as we are running down this rabbit hole…. J
>
>  
>
> My very original comment was “if this is a use case document, why is
> this concept in here with no associated use case for why I would need
> it? Could we have a use case please”
>
>  
>
> As the comment referred to multiple subnets, I would then observe that
> as far as IP is concerned, a subnet traditionally corresponds to a
> broadcast domain. These days I do not necessarily need to implement it
> via traditional bridging, and a lot of traditional discovery is
> changing to being database driven configuration. But I would have no
> trouble noting that a broadcast domain that also corresponds to a
> subnet has useful properties at a bunch of levels as a subnet
> prefix/mask becomes a convenient shorthand for the set, although a VNI
> is an even more convenient shorthand J  But if I want to run a single
> network as if it were a subnet using established tools, fine….
>
>  
>
> What I am less clear on is constructing a virtual network of multiple
> subnets and creating a virtual topology when AFAIK this does not get
> me much.
>

You get the ability to scope these discovery domains in ways that
correspond to IP address ranges, which is already widely used in IP.

I.e., you get to emulate how IP works.

> Am I simply scaling a single community of interest to which common
> policies apply? IN which case most of the properties a broadcast
> domain gets me, I’d want to see at L3.  Am I defining relationships
> between dissimilar communities of interest, which is wildly
> overloading the concept… As noted above policy could equally be
> expressed as VNI relationships, which likely is an equally useful
> abstraction.
>

The way in which these subnets are implemented may vary, as may the
discovery mechanism. But having them correspond to IP address ranges has
the direct benefit of emulating *existing* behavior of IP.

Let's put it another way - if you don't allow IP subnet virtualization,
you end up with a virtual network on which some IP topologies cannot be
deployed. That's an unnecessarily limitation.

Joe

> *Sent:* Saturday, August 13, 2016 10:30 AM

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 15 Aug 2016 22:54:45 +0000

Hi Joe,

thanks for the references to these RFCs, in particular to RFC 3819 which I was not aware of.

I think the references make very clear, that the term “subnet” is overloaded and therefore context dependent in meaning.

I do not want to bother you with a detailed analysis, but my observation is as follows:

The meaning of the term subnet is context dependent
- Layer-2 subnet in the sense of an object that forwards packets
- Layer-3 subnet in the sense of an object that forwards packets
- network prefix in the sense of an object that is a portion of an address plan, more precisely a subtree of a binary tree.

Adding to this ambiguity is the fact that subnet number (IPv4) and subnet ID (IPv6) relate to the Layer-3 subnet context of “subnet” only (not to the layer 2 subnet context) but do not identify a layer-3 subnet as a global identifier, rather play the role of a locator in the binary subtree with local significance only. This appears to be similar to the locator ID separation problem addressed by LISP.

Given this and Dave’s additional comments regarding: “please provide a use case please” may I kindly ask you to provide a use case with “context tag” or perhaps using the term network prefix instead of subnet where appropriate.

In particular I would be interested in a use case describing your stated requirement for “revisitation, where a single node participates multiple times in an overlay”. Could you please clarify the cardinality relations in this use case, e.g. do you mean

-        One physical interface to appear like multiple physical interfaces (such as a single physical NIC to appear as multiple VNICs)?

-        One physical interface (typically Ethernet Interface or station)  to be associated with one MAC addresses at Layer 2, where multiple IP addresses are associated with that MAC address, where said IP addresses belong to multiple Layer3 subnets., thus multiple Layer3 subnets associated with the same Layer2 subnet?

-        One physical interface (typically Ethernet Interface or station)  to be associated with multiple MAC addresses at Layer 2, where each of that MAC addresses is assigned one IP address (one to one relation between Layer3 subnet and Layer2 subnet, but multiple layer2 subnets on the same physical interface (Ethernet station i.e. PNIC or VNIC)?

Best Regards, Lothar
PS: Given that we live in times of emerging software defined networks, it is increasingly important WHAT an orchestration software defines when it defines a “network” or a “subnet”, and rapidly becoming irrelevant what context tag was not explicitly spelled out in an IETF RFC. So I recommend to analyse WHAT it is, that the OpenStack method “create network” creates. It may be an empty binding between a L2-subnet and a L3-subnet with all details and sizes yet undefined, but with a handle in form of a globally unique identifier in the form of a UUID, and the problem solved is the lack of a global identifier that is not a locator or address.

Von: Joe Touch [mailto:[email-masked]]
Gesendet: Sonntag, 14. August 2016 01:45
An: Reith, Lothar <[email-masked]>; David Allan I <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
Betreff: Re: AW: [nvo3] FW: Call for interest on NVO3 use case draft

Unfortunately there is no distinction made between a L2-subnet (aka a broadcast domain, or a MEF EVC, or o broadcast domain equivalent achieved without broadcast such as EVPN) and a L3-subnet (the object that does not appear in any information  model that I am aware of, but which has a size which is defined by a subnet-mask and which supports the use case of “change the IP-address range assigned to that subnet”.
The reason that L2 broadcast domain and L3 subnet (as per RFC1812) coincide is that is the basis of most L3:L2 mapping mechanisms, e.g., ARP (RFC826) or ARP emulation (RFC1577).

And the concept of an L3 subnet is pervasive in many RFCs, being the basis of hierarchical IP forwarding since its inception. There's even a specific RFC advising on the design of L2 subnets to support L3 subnets (3819).

These are very old and fundamental concepts to the Internet architecture. Any notion of virtualizing L3 needs to deal with them.

Joe

Lothar

Von: nvo3 [mailto:[email-masked]] Im Auftrag von Joe Touch
Gesendet: Samstag, 13. August 2016 19:30
An: David Allan I <[email-masked]><mailto:[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [nvo3] FW: Call for interest on NVO3 use case draft

Joe

That‘s my question
Dave

Cheers
Dave

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 16:07:09 -0700

On 8/15/2016 3:54 PM, Reith, Lothar wrote:
> I think the references make very clear, that the term “subnet” is
> overloaded and therefore context dependent in meaning.
>

It's almost always more useful to be clear about the way in which the
term is used, but IMO "subnet" is an L3 term that refers to addressing.
Everything else derives from that.

> - network prefix in the sense of an object that is a portion of an
> address plan, more precisely a subtree of a binary tree.
>

L2 doesn't have subnets; a specific L2 *is* a subnet to L3.

L3 subnets are defined by having a common bit-aligned address prefix.

>  Adding to this ambiguity is the fact that subnet number (IPv4) and
> subnet ID (IPv6) relate to the Layer-3 subnet context of “subnet” only
>
That's because subnet is an L3 term.

> (not to the layer 2 subnet context)
>
There is no L2 subnet. An L3 subnet is often - but not always - mapped
to a single L2 *network*.

> but do not identify a layer-3 subnet as a global identifier, rather
> play the role of a locator in the binary subtree with local
> significance only. This appears to be similar to the locator ID
> separation problem addressed by LISP.
>
That's exactly because LISP turns the encapsulation layer into what is
effectively an L2 network. The problem of mapping the inner and outer
addresses in LISP is the same as ARP, except that it requires
determining LISP egress rather than destination.

That's why we called the protocol to solve this "BARP" - it combines BGP
and ARP - when we developed it for what we called "recursive routers" in
the late 90s in our X-Bone system.

> Given this and Dave’s additional comments regarding: “please provide a
> use case please” may I kindly ask you to provide a use case with
> “context tag” or perhaps using the term network prefix instead of
> subnet where appropriate.
>
>  
>
> In particular I would be interested in a use case describing your
> stated requirement for “revisitation, where a single node participates
> multiple times in an overlay”. Could you please clarify the
> cardinality relations in this use case, e.g. do you mean
>
> -        One physical interface to appear like multiple physical
> interfaces (such as a single physical NIC to appear as multiple VNICs)?
>
> -        One physical interface (typically Ethernet Interface or
> station)  to be associated with one MAC addresses at Layer 2, where
> multiple IP addresses are associated with that MAC address, where said
> IP addresses belong to multiple Layer3 subnets., thus multiple Layer3
> subnets associated with the same Layer2 subnet?
>
> -        One physical interface (typically Ethernet Interface or
> station)  to be associated with multiple MAC addresses at Layer 2,
> where each of that MAC addresses is assigned one IP address (one to
> one relation between Layer3 subnet and Layer2 subnet, but multiple
> layer2 subnets on the same physical interface (Ethernet station i.e.
> PNIC or VNIC)?
>
First, if you're thinking about physical anything, you're limiting
yourself to one layer of virtualization. That's unnecessary.

So let's assume that when you say "physical" you really mean "in the
lowest layer of virtualization" (i.e., the base case of what is
ultimately a recursive structure  - e.g., see www.isi.edu/rna, which is
a generalization of the X-Bone architecture).

When I say "revisitation", I mean one base L3 interface that acts like
multiple NVO3 L3 interfaces.

That is accomplished by associating it with multiple virtual L2 (L2 over
L3), each virtual-L2 of which is associated with one virtual L3.

None if this is what you're describing above; you're stuck at the base
layer L2, which is below where NVO3 operates.

Joe
>
>  
>
>  
>
> Best Regards, Lothar
>
> PS: Given that we live in times of emerging software defined networks,
> it is increasingly important WHAT an orchestration software defines
> when it defines a “network” or a “subnet”, and rapidly becoming
> irrelevant what context tag was not explicitly spelled out in an IETF
> RFC. So I recommend to analyse WHAT it is, that the OpenStack method
> “create network” creates. It may be an empty binding between a
> L2-subnet and a L3-subnet with all details and sizes yet undefined,
> but with a handle in form of a globally unique identifier in the form
> of a UUID, and the problem solved is the lack of a global identifier
> that is not a locator or address.
>
>  
>
>  
>
> *Von:*Joe Touch [mailto:[email-masked]]
> *Gesendet:* Sonntag, 14. August 2016 01:45
> *An:* Reith, Lothar <[email-masked]>; David Allan I
> <[email-masked]>
> *Betreff:* Re: AW: [nvo3] FW: Call for interest on NVO3 use case draft
>
>  
>
>  
>
>  
>
> basis of hierarchical IP forwarding since its inception. There's even
> a specific RFC advising on the design of L2 subnets to support L3
> subnets (3819).
>
>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>
> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>; Bocci, Matthew (Nokia -
> GB) <[email-masked]> <mailto:[email-masked]>
> SO I’m looking for the draft to provide a use case for this vs. simply
> mentioning  subnetting without any context J 
>
>  
>
> Cheers
>
> Dave
>
>  
>
> tunnel or to a set of tunnels that transparently acts as such - just
> as a subnet in the Internet base network corresponds to a shared
> access link or a set of links that transparently act as such (e.g.,
> switched ethernet).
>
> Joe
>
>  
>
>  
>
>  
>

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 15 Aug 2016 23:42:38 +0000

Hi Joe,

I must admit I am puzzled a bit because you provided the reference to RFC3819 which states: “this document defines a subnetwork as a layer 2 network, which is a
network that does not rely upon the services of IP routers to forward packets between parts of the subnetwork.”

Lothar

Von: Joe Touch [mailto:[email-masked]]
Gesendet: Dienstag, 16. August 2016 01:07
An: Reith, Lothar <[email-masked]>; David Allan I <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
Betreff: Re: AW: AW: [nvo3] FW: Call for interest on NVO3 use case draft

It's almost always more useful to be clear about the way in which the term is used, but IMO "subnet" is an L3 term that refers to addressing. Everything else derives from that.

 Adding to this ambiguity is the fact that subnet number (IPv4) and subnet ID (IPv6) relate to the Layer-3 subnet context of “subnet” only
That's because subnet is an L3 term.

(not to the layer 2 subnet context)
There is no L2 subnet. An L3 subnet is often - but not always - mapped to a single L2 *network*.

but do not identify a layer-3 subnet as a global identifier, rather play the role of a locator in the binary subtree with local significance only. This appears to be similar to the locator ID separation problem addressed by LISP.
That's exactly because LISP turns the encapsulation layer into what is effectively an L2 network. The problem of mapping the inner and outer addresses in LISP is the same as ARP, except that it requires determining LISP egress rather than destination.

That's why we called the protocol to solve this "BARP" - it combines BGP and ARP - when we developed it for what we called "recursive routers" in the late 90s in our X-Bone system.

-        One physical interface (typically Ethernet Interface or station)  to be associated with multiple MAC addresses at Layer 2, where each of that MAC addresses is assigned one IP address (one to one relation between Layer3 subnet and Layer2 subnet, but multiple layer2 subnets on the same physical interface (Ethernet station i.e. PNIC or VNIC)?
First, if you're thinking about physical anything, you're limiting yourself to one layer of virtualization. That's unnecessary.

So let's assume that when you say "physical" you really mean "in the lowest layer of virtualization" (i.e., the base case of what is ultimately a recursive structure  - e.g., see www.isi.edu/rna<http://www.isi.edu/rna>, which is a generalization of the X-Bone architecture).

When I say "revisitation", I mean one base L3 interface that acts like multiple NVO3 L3 interfaces.

That is accomplished by associating it with multiple virtual L2 (L2 over L3), each virtual-L2 of which is associated with one virtual L3.

None if this is what you're describing above; you're stuck at the base layer L2, which is below where NVO3 operates.

Joe

Best Regards, Lothar

An: Reith, Lothar <[email-masked]><mailto:[email-masked]>; David Allan I <[email-masked]><mailto:[email-masked]>

Joe

Lothar

Joe

That‘s my question
Dave

Cheers
Dave

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 17:19:35 -0700

On 8/15/2016 4:42 PM, Reith, Lothar wrote:
>
> Hi Joe,
>
>  
>
> I must admit I am puzzled a bit because you provided the reference to
> RFC3819 which states: “this document defines a subnetwork
>
i.e., subnet

> as a layer 2 network,

That's exactly what I state below...

> which is a
>
> network that does not rely upon the services of IP routers to forward
> packets between parts of the subnetwork.”
>

A L2 network - by definition - doesn't require IP forwarding inside.

I'm not sure what the issue is. This is consistent with what I say below.

Joe

> *Gesendet:* Dienstag, 16. August 2016 01:07
> *Betreff:* Re: AW: AW: [nvo3] FW: Call for interest on NVO3 use case draft
>
>  
>
>  
>
>  
>
> term is used, but IMO "subnet" is an L3 term that refers to
> addressing. Everything else derives from that.
>
>
>      Adding to this ambiguity is the fact that subnet number (IPv4)
>     and subnet ID (IPv6) relate to the Layer-3 subnet context of
>     “subnet” only
>
>     but do not identify a layer-3 subnet as a global identifier,
>     rather play the role of a locator in the binary subtree with local
> That's why we called the protocol to solve this "BARP" - it combines
> BGP and ARP - when we developed it for what we called "recursive
> routers" in the late 90s in our X-Bone system.
>
>
>     Given this and Dave’s additional comments regarding: “please
>     provide a use case please” may I kindly ask you to provide a use
>     case with “context tag” or perhaps using the term network prefix
>     instead of subnet where appropriate.
>
>      
>
>     stated requirement for “revisitation, where a single node
>     participates multiple times in an overlay”. Could you please
>     clarify the cardinality relations in this use case, e.g. do you mean
>
>     station)  to be associated with one MAC addresses at Layer 2,
>     where multiple IP addresses are associated with that MAC address,
>     where said IP addresses belong to multiple Layer3 subnets., thus
>     multiple Layer3 subnets associated with the same Layer2 subnet?
>
>     where each of that MAC addresses is assigned one IP address (one
>     to one relation between Layer3 subnet and Layer2 subnet, but
>     multiple layer2 subnets on the same physical interface (Ethernet
>     station i.e. PNIC or VNIC)?
>
> ultimately a recursive structure  - e.g., see www.isi.edu/rna
> <http://www.isi.edu/rna>, which is a generalization of the X-Bone
> architecture).
>
> That is accomplished by associating it with multiple virtual L2 (L2
> over L3), each virtual-L2 of which is associated with one virtual L3.
>
>     PS: Given that we live in times of emerging software defined
>     networks, it is increasingly important WHAT an orchestration
>     software defines when it defines a “network” or a “subnet”, and
>     rapidly becoming irrelevant what context tag was not explicitly
>     spelled out in an IETF RFC. So I recommend to analyse WHAT it is,
>     that the OpenStack method “create network” creates. It may be an
>     empty binding between a L2-subnet and a L3-subnet with all details
>     and sizes yet undefined, but with a handle in form of a globally
>     unique identifier in the form of a UUID, and the problem solved is
>     the lack of a global identifier that is not a locator or address.
>
>      
>
>      
>
>     *An:* Reith, Lothar <[email-masked]>
>     <mailto:[email-masked]>; David Allan I
>     <[email-masked]> <mailto:[email-masked]>
>     Unfortunately there is no distinction made between a L2-subnet
>     (aka a broadcast domain, or a MEF EVC, or o broadcast domain
>     equivalent achieved without broadcast such as EVPN) and a
>     L3-subnet (the object that does not appear in any information
>      model that I am aware of, but which has a size which is defined
>     by a subnet-mask and which supports the use case of “change the
>     IP-address range assigned to that subnet”.
>
>     coincide is that is the basis of most L3:L2 mapping mechanisms,
>     e.g., ARP (RFC826) or ARP emulation (RFC1577).
>
>     And the concept of an L3 subnet is pervasive in many RFCs, being
>     the basis of hierarchical IP forwarding since its inception.
>     There's even a specific RFC advising on the design of L2 subnets
>     to support L3 subnets (3819).
>
>
>
>      Part of the reason for complexity is the lack of a proper
>     definition of this object in the information model.
>
>      
>
>     If I am wrong – I would be happy to be corrected by someone who
>     can point me to an authoritative definition of the term subnet as
>     an object that supports the use case “change address range
>     assigned to subnet” without specifying how the subnet is built as
>     layer 2 construct (e.g. as Ethernet yellow cable, VLAN in a
>     Switched Ethernet domain, VXLAN overlay, EVPN, MEF EVC or ATM
>     point to point link).
>
>
>     Thanks to OpenStack for  finally fixing the problem by introducing
>     the method “create network”, which creates – exactly – this
>     missing object in an abstract way.
>
>      
>
>     So Dave’s question is very valid, simply because the term
>     “subnetting” is not properly defined – unless the authors point to
>     a reference RFC where the term is defined in an authoritative way.
>
>      
>
>     Lothar
>
>      
>
>      
>
>      
>
>     You want the properties of a subnet and/or to emulate the behavior
>     of a shared link, i.e., to limit the scope of various protocols,
>     support revisitation, where a single node participates multiple
>     times in an overlay), and basically any subnet-based resource
>     discovery.
>
>     Joe
>
>
>
>
>      
>
>     That‘s my question
>
>     Dave
>
>      
>
>     normally think of subnetting as a  convenient address
>     summarization technique dependent on topology, and with an overlay
>     I don’t have a topology.
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 15 Aug 2016 20:57:26 -0400

Joe, you are citing two different definitions.  And while they are 
usually congruent, the IP Prefix (the definition as seen by L3) and the 
domain of L2 forwarding (the definition as seen by L2) are not always 
the same.  There have been more than a few designs and deployments over 
the years where the L3-visible subnet definition is actually provided by 
L3 /32 IPv4 forwarding (over a constrained scope).  There have also been 
hybrids.

I believe Lothar is quite correct in noting that there are multiple 
closely related but not identical definitions, and that we often get 
ourselves in trouble by treating them as identical.

Yours,
Joel

On 8/15/16 8:19 PM, Joe Touch wrote:
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 Aug 2016 18:29:25 -0700

On 8/15/2016 5:57 PM, Joel M. Halpern wrote:
> usually congruent, the IP Prefix (the definition as seen by L3) and
> the domain of L2 forwarding (the definition as seen by L2) are not
> always the same.  There have been more than a few designs and
> deployments over the years where the L3-visible subnet definition is
> actually provided by L3 /32 IPv4 forwarding (over a constrained
> scope).  There have also been hybrids.
There are exceptions that *emulate* the definition I've been using
(e.g., using ICMP redirects and "transparent" forwarding that doesn't
change hopcount to mimic L2 relays) or that try very hard to do
something that deliberately breaks this definition, yes - but that's why
we wrote RFC3819. The point of that RFC is that L3 subnets work best
when they match L2 networks that have full reachability without L3 help.
> ourselves in trouble by treating them as identical.
RFC3819 explains why we get into trouble primarily when these two
concepts do not align. That's not a good reason to do otherwise.

Joe

---

From: Haoweiguo <[email-masked]>
Date: Wed, 17 Aug 2016 01:40:15 +0000

Hi,
I also agree that treating L2 broadcast domain and L3 subnet as identical is not accurate, but it is only the minor issue for the whole text. Through these years development, NVO3 is no longer a concept and is becoming pervasive in data center networks. However, a clear use case draft is still needed to summarize the typical applications for NVO3, I think this draft is clear and ready for publishing.
Thanks,
weiguo

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2016年8月16日 8:57
收件人: Joe Touch; Reith, Lothar; David Allan I
抄送: Bocci, Matthew (Nokia - GB); [email-masked]
主题: Re: [nvo3] FW: Call for interest on NVO3 use case draft

Joe, you are citing two different definitions.  And while they are usually congruent, the IP Prefix (the definition as seen by L3) and the domain of L2 forwarding (the definition as seen by L2) are not always the same.  There have been more than a few designs and deployments over the years where the L3-visible subnet definition is actually provided by
L3 /32 IPv4 forwarding (over a constrained scope).  There have also been hybrids.

I believe Lothar is quite correct in noting that there are multiple closely related but not identical definitions, and that we often get ourselves in trouble by treating them as identical.

Yours,
Joel

On 8/15/16 8:19 PM, Joe Touch wrote:
>> That's exactly because LISP turns the encapsulation layer into what 
>> is effectively an L2 network. The problem of mapping the inner and 
>> outer addresses in LISP is the same as ARP, except that it requires 
>> None if this is what you're describing above; you're stuck at the 
>> base layer L2, which is below where NVO3 operates.
>>
>> Joe
>>
>>
>>
>>
>>
>>     Best Regards, Lothar
>>

---

From: Lucy yong <[email-masked]>
Date: Fri, 19 Aug 2016 14:27:31 +0000

Hi Allan,

Thank you for your support on publishing the draft and giving good comments/suggestions. Your comments and triggered discussions clearly show that the draft has some terms overloaded or not used properly, which needs to be fixed. Yes, we can improve the structure and elaborate the motivation for different use cases.

Thank you, Joe, Reith, and Joel for the discussions on the comments, which is helpful to clear the text problem in Section 4.2.

If the WG gets a consensus for publishing this draft,  we will revise the draft to address these issues;  hope for you to review again.

Thanks/Regards,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Friday, August 12, 2016 6:17 PM
To: [email-masked]; Bocci, Matthew (Nokia - GB)
Subject: [nvo3] FW: Call for interest on NVO3 use case draft

Hi Matthew:

My 2 cents
Dave

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Aug 2016 14:11:55 -0700

Hi, Lucy,

On 8/19/2016 7:27 AM, Lucy yong wrote:
>
> /Thank you, Joe, Reith, and Joel for the discussions on the comments,
> which is helpful to clear the text problem in Section 4.2./
>
Let me know if you need text there or if you want feedback on the update
of that section in particular.

Joe

---

From: Lucy yong <[email-masked]>
Date: Fri, 19 Aug 2016 22:05:02 +0000

Hi Joe,

Let's wait on the WG consensus and decision. If continually working on the draft for publishing, I will propose some structure changes on section 4 and revised text of the section, then let you review first. Thank you so much to offer help here.:)

Regards,
Lucy

From: Joe Touch [mailto:[email-masked]]
Sent: Friday, August 19, 2016 4:12 PM
To: Lucy yong; David Allan I; [email-masked]; Bocci, Matthew (Nokia - GB)
Subject: Re: [nvo3] Call for interest on NVO3 use case draft

Hi, Lucy,

On 8/19/2016 7:27 AM, Lucy yong wrote:
Thank you, Joe, Reith, and Joel for the discussions on the comments, which is helpful to clear the text problem in Section 4.2.
Let me know if you need text there or if you want feedback on the update of that section in particular.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 Aug 2016 15:07:10 -0700

Hi, Lucy, et al.,

Sure - just offering if/when useful.

Joe

On 8/19/2016 3:05 PM, Lucy yong wrote:
>
> /Hi Joe,/
>
> / /
>
> /Let’s wait on the WG consensus and decision. If continually working
> on the draft for publishing, I will propose some structure changes on
> section 4 and revised text of the section, then let you review first.
> Thank you so much to offer help here.:)/
>
> / /
>
> /Regards,/
>
> /Lucy  /
>
> / /
>
> *Sent:* Friday, August 19, 2016 4:12 PM
> *To:* Lucy yong; David Allan I; [email-masked]; Bocci, Matthew (Nokia - GB)
> *Subject:* Re: [nvo3] Call for interest on NVO3 use case draft
>
>  
>
> Hi, Lucy,
>
>  
>
>     /Thank you, Joe, Reith, and Joel for the discussions on the
>     comments, which is helpful to clear the text problem in Section 4.2./
>

---

From: Lucy yong <[email-masked]>
Date: Sat, 27 Aug 2016 09:17:35 +0000

Hi Allan, Joe, et al,

Regarding the structure concern in Section 4, I propose to split two cases into two sections: 1) Supporting Multiple Technologies 2) DC application with multiple virtual networks, i.e. DMZ case.  Draft already explains why both cases are useful.

The use case in Section 4.2 (-08) is described with a problem, i.e. using subnet. It should be “A tenant network is configured with multiple subnetworks”;  the example is to show that some subnetworks may be configured as an L2VN while another is configured as L3.  The motivation of such configuration is that, within DC,  L2 is the often way for VMs connections, however, BIG L2 broadcast domains across DC sites can cause a concern in terms of WAN security, scalability, etc. Therefore, an L3VN is configured to interconnect DC L2VNs over a WAN. IMO: this is different from the DMZ intent.

If we agree that this is valuable  and important case to document, we can keep it. If not, we can simply remove the case (we have enough use cases here ☺). Please let me know.

Attached is the revised version accordingly. Please review and help to improve it where necessary.

Thanks/Regards,
Lucy

Hi Matthew:

My 2 cents
Dave

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2016 14:39:35 -0700

Hi, Lucy,

On 8/27/2016 2:17 AM, Lucy yong wrote:
>
> /Hi Allan, Joe, et al,/
>
> / /
>
> /Regarding the structure concern in Section 4, I propose to split two
> cases into two sections: 1) Supporting Multiple Technologies 2) DC
> application with multiple virtual networks, i.e. DMZ case.  Draft
> already explains why both cases are useful./
>
> / /
>
> /The use case in Section 4.2 (-08) is described with a problem, i.e.
> using subnet. It should be “A tenant network is configured with
> multiple subnetworks”;  the example is to show that some subnetworks
> may be configured as an L2VN while another is configured as L3.
> /
>

I'm confused by this description. L3 subnets are contiguous address
ranges that are reachable from each other without use of a router (i.e.,
without decrementing the TTL).

L3 doesn't care whether the L2 is virtual or not.

> /The motivation of such configuration is that, within DC,  L2 is the
> often way for VMs connections, however, BIG L2 broadcast domains
> across DC sites can cause a concern in terms of WAN security,
> scalability, etc. /
>

There are many ways to address L2 (virtual or not) scale and security,
including proxy ARP servers local to each physical site.

> /Therefore, an L3VN is configured to interconnect DC L2VNs over a WAN.
> IMO: this is different from the DMZ intent./
>
A DMZ is not necessarily related to a subnet at all.

> //
>
> / /
>
> /If we agree that this is valuable  and important case to document, we
> can keep it. If not, we can simply remove the case (we have enough use
> cases here //J//). Please let me know./
>
> / /
>
> /Attached is the revised version accordingly. Please review and help
> to improve it where necessary. /
>

I found the text in the draft in Sec 4.3 confusing along the lines
mentioned above. The doc needs to be more clear about what it means when
using the term subnet, and this should be the L3 definition.

Some notes below, embedded in a copy of that text:

> 4.3. Tenant Network with Multiple Subnetworks
>
>    A tenant network may be configured with  multiple subnetworks. One
change to:

multiple Internet subnets, as defined in RFC1812.

>    example, when a tenant network are across multiple DC sites, DC
>    operators may configure an L2VN within each DC site and an L3VN over
change to:

within each DC site interconnected by routers (gateways) as an L3VN over

>    WANs for the network. The motivation for this configuration is that
>    L2VN is a common way connecting VMs within a DC; however a big
>
>
>
> Yong, et al.                                                   [Page 9]
> 
> Internet-Draft               NVO3 Use Case                  August 2016
>
>    broadcast domain across multiple DC sites and WAN networks raises

across multiple DC sites and spanning wide area distances over WAN
networks raises
>    security and scalability concerns. Alternative is to use an L3VN to
>    interconnect these L2VNs at DC sites, 

I don't understand the above. That is the same solution as the first
example you have given.

You either have one L2VN that spans DCs or separate L2VNs. Those
separate L2VNs are L3 subnets, which - by definition - need a gateway in
order to be connected together as a network.

Joe

Joe

---

From: Lucy yong <[email-masked]>
Date: Mon, 29 Aug 2016 22:03:17 +0000

Hi Joe,

Please see my comments inline below.
From: Joe Touch [mailto:[email-masked]]
Sent: Monday, August 29, 2016 4:40 PM
To: Lucy yong; David Allan I; [email-masked]; Bocci, Matthew (Nokia - GB)
Subject: Re: Call for interest on NVO3 use case draft

Hi, Lucy,

The use case in Section 4.2 (-08) is described with a problem, i.e. using subnet. It should be “A tenant network is configured with multiple subnetworks”;  the example is to show that some subnetworks may be configured as an L2VN while another is configured as L3.

I'm confused by this description. L3 subnets are contiguous address ranges that are reachable from each other without use of a router (i.e., without decrementing the TTL).

L3 doesn't care whether the L2 is virtual or not.
[Lucy] Could you pls look at the Section 4.3 in attached version and will that description a bit clear to you?

The motivation of such configuration is that, within DC,  L2 is the often way for VMs connections, however, BIG L2 broadcast domains across DC sites can cause a concern in terms of WAN security, scalability, etc.

There are many ways to address L2 (virtual or not) scale and security, including proxy ARP servers local to each physical site.
[Lucy] Right. Here gives one NV03 implementation example. No intention to list all of them. Agree there are many ways to address security and scale concerns.

Therefore, an L3VN is configured to interconnect DC L2VNs over a WAN. IMO: this is different from the DMZ intent.
A DMZ is not necessarily related to a subnet at all.
[Lucy] right, DMZ is described in the attached version in Section 4.2. please take a look.

I found the text in the draft in Sec 4.3 confusing along the lines mentioned above. The doc needs to be more clear about what it means when using the term subnet, and this should be the L3 definition.
[Lucy] you mean subnetwork = subnet.

multiple Internet subnets, as defined in RFC1812.
[Lucy] Do they have to be subnets, i.e. under one network mask? L3VN can learn the routes from DC, no reason to limit to all routes from a DC under one subnet although operator may design that way.

   WANs for the network. The motivation for this configuration is that
   L2VN is a common way connecting VMs within a DC; however a big
[Lucy] I will take your text. Does this mean you are OK with this use case?

Thanks,
Lucy

Yong, et al.                                                   [Page 9]

across multiple DC sites and spanning wide area distances over WAN networks raises

I don't understand the above. That is the same solution as the first example you have given.

You either have one L2VN that spans DCs or separate L2VNs. Those separate L2VNs are L3 subnets, which - by definition - need a gateway in order to be connected together as a network.

Joe

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2016 15:25:09 -0700

Hi, Lucy,

On 8/29/2016 3:03 PM, Lucy yong wrote:
>
> /Hi Joe,/
>
> / /
>
> /Please see my comments inline below./
>
> *Sent:* Monday, August 29, 2016 4:40 PM
> *Subject:* Re: Call for interest on NVO3 use case draft
>
>  
>
> Hi, Lucy,
>
>  
>
>     /Regarding the structure concern in Section 4, I propose to split
>     two cases into two sections: 1) Supporting Multiple Technologies
>     2) DC application with multiple virtual networks, i.e. DMZ case.
>      Draft already explains why both cases are useful./
>
>     / /
>
>     /The use case in Section 4.2 (-08) is described with a problem,
>     i.e. using subnet. It should be “A tenant network is configured
>     with multiple subnetworks”;  the example is to show that some
>     subnetworks may be configured as an L2VN while another is
>     configured as L3. /
>
>
> ranges that are reachable from each other without use of a router
> (i.e., without decrementing the TTL).
>
> */[Lucy] Could you pls look at the Section 4.3 in attached version and
> will that description a bit clear to you? /*
>

I did, but it is not clear. You have multiple L2s that are
interconnected without using an L3 router. I don't understand what that
means.

> *//*
> */[Lucy] Right. Here gives one NV03 implementation example. No
> intention to list all of them. Agree there are many ways to address
> security and scale concerns./*
>
> */[Lucy] right, DMZ is described in the attached version in Section
> 4.2. please take a look./*
>

OK ( though that definition should use the term "subnet" and focus on
addresses, not whether it is a single computer or not.

> *//*
> mentioned above. The doc needs to be more clear about what it means
> when using the term subnet, and this should be the L3 definition.
>
> */[Lucy] you mean subnetwork = subnet. /*
>

I mean that you need to cite RFC1812 and be clear that this is a set of
adjacent addresses that can be represented by an L3 mask and whose
components are all interconnected without need for an L3 gateway.

> *//*
> */[Lucy] Do they have to be subnets, i.e. under one network mask? L3VN
> can learn the routes from DC, no reason to limit to all routes from a
> DC under one subnet although operator may design that way./*
>
Each subnet is under one net mask (by definition of subnet).

That means one route per subnet AND that the L3VN needs to connect to
each subnet.

If that's not the case, then you have a different model (more like BGP),
but then you're no longer talking about subnets inside the DC anymore.

> *//*
> */[Lucy] I will take your text. Does this mean you are OK with this
> use case?/*
>

Sure.

> *//*
> */ /*
> */Thanks,/*
> */Lucy/*
> separate L2VNs are L3 subnets, which - by definition - need a gateway
> in order to be connected together as a network.
>
> Joe
>
> Joe
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 29 Aug 2016 22:42:56 +0000

Hi Joe,

See inline below.

From: Joe Touch [mailto:[email-masked]]
Sent: Monday, August 29, 2016 5:25 PM
To: Lucy yong; David Allan I; [email-masked]; Bocci, Matthew (Nokia - GB)
Subject: Re: Call for interest on NVO3 use case draft

Hi, Lucy,

To: Lucy yong; David Allan I; [email-masked]<mailto:[email-masked]>; Bocci, Matthew (Nokia - GB)

Hi, Lucy,

I did, but it is not clear. You have multiple L2s that are interconnected without using an L3 router. I don't understand what that means.

OK ( though that definition should use the term "subnet" and focus on addresses, not whether it is a single computer or not.
[Lucy] agree.

I mean that you need to cite RFC1812 and be clear that this is a set of adjacent addresses that can be represented by an L3 mask and whose components are all interconnected without need for an L3 gateway.
[Lucy] Agree if we describe this case. Pls see below.

[Lucy] yes

That means one route per subnet AND that the L3VN needs to connect to each subnet.
[Lucy] A operator can design in this way too. However, 4.3 is not targeted for this case. That was my description mistake.

If that's not the case, then you have a different model (more like BGP), but then you're no longer talking about subnets inside the DC anymore.
[Lucy] Yes, BGP is what operator to use for this case. Sorry to make that confusion. Any suggestion to describe the case?

Sure.

Thanks,
Lucy

Yong, et al.                                                   [Page 9]

You either have one L2VN that spans DCs or separate L2VNs. Those separate L2VNs are L3 subnets, which - by definition - need a gateway in order to be connected together as a network.
[Lucy] From tenant perspective, it gets one L2VPN, however operator can construct multiple  L2VNs and L3VN to achieve it. Make a sense?

Lucy

Joe

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 29 Aug 2016 18:04:12 -0700

Cutting this down to make it easier to track remaining issues...

On 8/29/2016 3:42 PM, Lucy yong wrote:
> */[Lucy] yes/*//
> */[Lucy] A operator can design in this way too. However, 4.3 is not
> targeted for this case. That was my description mistake. /*
>
OK.

> *//*
>
> If that's not the case, then you have a different model (more like
> BGP), but then you're no longer talking about subnets inside the DC
> anymore.
>
> */[Lucy] Yes, BGP is what operator to use for this case. Sorry to make
> that confusion. Any suggestion to describe the case? /*
>

That's not a subnet. That's creating an AS - otherwise, BGP won't peer
with the DC network.

> ...The motivation for this configuration is that
>
> */[Lucy] From tenant perspective, it gets one L2VPN, however operator
> can construct multiple  L2VNs and L3VN to achieve it. Make a sense?/*
>

>From a tenant perspective, if they get an L2VPN, they can neither see
nor know how it happens.

If it's L2 over L3, that creates a lot of problems - i.e., you're
basically restoring exactly the broadcast domain you thought you were
getting rid of.

If the L2 involves multiple L2s, something has to tie them together (an
L3) or you're layering (L2 over L2). The former is what I already
described above (it's an L3 net, not an L2 net), and if it's the latter,
it's still just one L2 net with all of the broadcast problems.

So whatever this is, it needs to be explained more clearly IMO.

Joe

---

From: Lucy yong <[email-masked]>
Date: Tue, 30 Aug 2016 01:27:10 +0000

Hi Joe,

Please see inline.
From: Joe Touch [mailto:[email-masked]]
Sent: Monday, August 29, 2016 8:04 PM
To: Lucy yong; David Allan I; [email-masked]; Bocci, Matthew (Nokia - GB)
Subject: Re: Call for interest on NVO3 use case draft

That's not a subnet. That's creating an AS - otherwise, BGP won't peer with the DC network.
[Lucy] Get it.

From a tenant perspective, if they get an L2VPN, they can neither see nor know how it happens.
[Lucy] true, but here is to provide a use case to support a tenant network

If it's L2 over L3, that creates a lot of problems - i.e., you're basically restoring exactly the broadcast domain you thought you were getting rid of.

If the L2 involves multiple L2s, something has to tie them together (an L3) or you're layering (L2 over L2). The former is what I already described above (it's an L3 net, not an L2 net), and if it's the latter, it's still just one L2 net with all of the broadcast problems.

So whatever this is, it needs to be explained more clearly IMO.
[Lucy] OK, I see your point. Since we already has BGP AS case described in Section 3. Maybe good to remove this case from the draft.

Lucy

Joe