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 protected]]
Gesendet: Sonntag, 14. August 2016 01:45
An: Reith, Lothar <[email protected]>; David Allan I 
<[email protected]>
Cc: Bocci, Matthew (Nokia - GB) <[email protected]>; [email protected]
Betreff: Re: AW: [nvo3] FW: Call for interest on NVO3 use case draft




On 8/13/2016 4:20 PM, Reith, Lothar wrote:
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”.
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).


 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).

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


On 8/13/2016 9:52 AM, David Allan I wrote:
Hi Joe

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 protected]]
Sent: Friday, August 12, 2016 8:20 PM
To: David Allan I 
<[email protected]><mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>; Bocci, Matthew (Nokia - GB) 
<[email protected]><mailto:[email protected]>
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 protected]<mailto:[email protected]>> 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 protected]] On Behalf Of Joe Touch
Sent: Friday, August 12, 2016 5:07 PM
To: David Allan I 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>; Bocci, Matthew (Nokia - GB) 
<[email protected]<mailto:[email protected]>>
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



_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to