Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Diego Garcia del Rio]

Some comments from my side,


I think the draft makes quite a few assumptions on specific
implementation details that are way too general to be considered
widely available.

Most of the TOR devices today already pay a double-pass penalty when
doing routing of traffic in/out of vxlan-type tunnels. Only the newest
generation can route into tunnels without additional passes. And are
definitively limited in being able to arbitrary select UDP ports on a
per tunnel basis. In fact, most are even limited at using more than
one VNID per "service" of sorts.

The IP-addressed based implementation which would, I assume, imply
assigning one or more CIDRs to a loopback interface on the ASBR-d is
also quite arbitrary and does not seem like a technically "clean"
solution. (besides burning tons of IPs). As a side-note, most PE-grade
routers i've worked with were quite limited in terms of IP addresses
used for tunnel termination and it wasn't that just a simple pool can
be used.

Wim's mentions on cases where the Application itself, hosted in a
datacenter, would be part of the option-C interconnect, was dismissed
without much discussion so far, while, if we look in detail at the
type of users which will even consider a complex topology like model-C
its most likely users and operators very familiar with MPLS VPNs in
the WAN. Those type of operators will most likely be very interested
in deploying MPLS or WAN-grade applications (i.e., virtual-routers or
other VNFs) in the DC and thus its highly likely that the interconnect
would not terminate at the NVE itself but rather the TS (the virtual
machine).

Also, the use of UDP ports at random would imply quite complex logic
on the ASBR-d IMHO. Im not saying its impossible, but since the
received packet now not only has to be received on a random (though
locally chosen) UDP port and this information preserved in the
pipeline to be able to do the double-tunnel-stitching, it sounds quite
complex. I am sure someone in the list will mention this has already
been implemented somewhere, and I won't argue with that. And let's not
even bring into account what this would do to any DC middlebox that
now has to look at vxlan over almost any random port. We have to go
back to the "is it a 4 or is it a 6 in byte x" heuristics to try to
guess whether the packet is vxlan or just something entirely different
running over IP.

In general I feel the proposed solution seems to be fitting of a
specific use-case which is not really detailed in the draft and does
not describe   a solution that would "elegantly" solve the issues at
hand. It just feels like we're using any available bit-space to stuff
data into places that do not necesarily belong.

Yes, MPLS encapsulations on virtual switches are not yet fully
available, and there can be some performance penalty on the TORs, but
the solutions are much cleaner from a control and data plane point of
view. Maybe I'm too utopic.


Best regards,

Diego




-

Hi,

The problem we are trying to solve is to reduce data center
GW/ASBR-d's forwarding table size, the motivation is same as
traditional MPLS VPN option-C. Currently, the most common practise on
ASBR-d is to terminate VXLAN encapsulation, look up local routing
table, and then perform MPLS encapsulation to the WAN network. ASBR-d
needs to maintain all VM's MAC/IP. In Option-C method, only transport
layer information needed to be maintained at GW/ASBR-d, the
scalability will be greatly enhanced. Traditonal Option-C is only for
MPLS VPN network interworking, because VXLAN is becoming pervasive in
data center,  the solution in this draft was proposed for the
heterogeneous network interworking.

The advantage of this solution is that only VXLAN encapsulation is
required for OVS/TOR. Unlike Wim's solution, east-west bound traffic
uses VXLAN encap, while north-south bound traffic uses MPLSoGRE/UDP
encap.

There are two solutions in this draft:

1. Using VXLAN tunnel destination IP for stitching at ASBR-d.

No data plane modification requirements on OVS or TOR switches, only
hardware changes on ASBR-d. ASBR-d normally is router, it has
capability to realize the hardware changes. It will consume many IP
addresses and the IP pool for allocation needs to be configured on
ASBR-d beforehand.

2. Using VXLAN destination UDP port for stitching at ASBR-d.

Compared with solution 1, less IP address will be consumed for
allocation. If UDP port range is too large, we can combine with
solution 1 and 2.

In this solution, both data plane modification changes are needed at
OVS/TOR and ASBR-d. ASBR-d also has capability to realize the hardware
changes. For OVS, it also can realize the data plane changes. For TOR
switch, it normally can't realize this function.  This solution mainly
focuses on pure software based overlay network, it has more
scalability. In public cloud data center, software based overlay
network is the majority case.



Whether us

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Haoweiguo]

Hi,

The problem we are trying to solve is to reduce data center GW/ASBR-d's 
forwarding table size, the motivation is same as traditional MPLS VPN option-C. 
Currently, the most common practise on ASBR-d is to terminate VXLAN 
encapsulation, look up local routing table, and then perform MPLS encapsulation 
to the WAN network. ASBR-d needs to maintain all VM's MAC/IP. In Option-C 
method, only transport layer information needed to be maintained at GW/ASBR-d, 
the scalability will be greatly enhanced. Traditonal Option-C is only for MPLS 
VPN network interworking, because VXLAN is becoming pervasive in data center,  
the solution in this draft was proposed for the heterogeneous network 
interworking.

The advantage of this solution is that only VXLAN encapsulation is required for 
OVS/TOR. Unlike Wim's solution, east-west bound traffic uses VXLAN encap, while 
north-south bound traffic uses MPLSoGRE/UDP encap.

There are two solutions in this draft:

1. Using VXLAN tunnel destination IP for stitching at ASBR-d.

No data plane modification requirements on OVS or TOR switches, only hardware 
changes on ASBR-d. ASBR-d normally is router, it has capability to realize the 
hardware changes. It will consume many IP addresses and the IP pool for 
allocation needs to be configured on ASBR-d beforehand.

2. Using VXLAN destination UDP port for stitching at ASBR-d.

Compared with solution 1, less IP address will be consumed for allocation. If 
UDP port range is too large, we can combine with solution 1 and 2.

In this solution, both data plane modification changes are needed at OVS/TOR 
and ASBR-d. ASBR-d also has capability to realize the hardware changes. For 
OVS, it also can realize the data plane changes. For TOR switch, it normally 
can't realize this function.  This solution mainly focuses on pure software 
based overlay network, it has more scalability. In public cloud data center, 
software based overlay network is the majority case.



Whether using solution 1 or 2 depends on the operators real envionment.



So I think our solution has no flaws, it works fine.

Thanks,

weiguo




From: BESS [bess-boun...@ietf.org] on behalf of John E Drake 
[jdr...@juniper.net]
Sent: Wednesday, November 18, 2015 2:49
To: Henderickx, Wim (Wim); EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi,

I think Wim has conclusively demonstrated that this draft has fatal flaws and I 
don’t support it.  I also agree with his suggestion that we first figure out 
what problem we are trying to solve before solving it.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 12:49 PM
To: EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there ca

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

Lucy, does not change anything but I did a typo
I meant to say every tenant needs a different VXLAN UDP destination port for 
upstream
[Lucy] In this solution, tenant and VXLAN UDP dst. port are orthogonal.  The 
VXLAN UDP dst. port on an upstream packet contains the info. for the outgoing 
label at DC ASBR.

Lucy
+ receive port for downstream on NVE

From: Lucy yong mailto:lucy.y...@huawei.com>>
Date: Tuesday 17 November 2015 at 11:54
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
"thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>, BESS 
mailto:bess@ietf.org>>
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

For this to work every tenant needs a different VXLAN UDP destination 
port/receive port.

[Lucy] this is not right. For the traffic from DC ASBR -> NVE, only one UDP dst 
port is used; for the traffic from NVE-> DC ASBR, DC ASBR signaled UDP port 
number will be used. Tenant traffic is segregated by VNID, not UDP port. At an 
NVE, the traffic going toward the same remote PE will be encapsulated w/ VXLAN 
and the same UDP dst port number even the traffic may belong to different VNs. 
In short, tenant and UDP port are orthogonal; the solution just uses UDP port 
to indicate the outgoing mpls label for the packets at DC ASBR when it receives 
packets from NVEs.

Lucy

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 11:49 AM
To: thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?





2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes



I wrote the above based on the i

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

Hi John,

I don’t know what is the fatel flaw here. The solution works. It is matter of 
the preference. Even if the way of UDP port proposed in the draft is not 
acceptable, we can use IP addresses to achieve it. The key is that BESS WG 
needs option C solution(s) for the use case that the applications are contexts 
where overlays are present is when workloads (VMs or baremetal) need to be 
interconnected with VPNs. In these contexts, there can be reasons to want 
Option C to reduce the state on ASBRs.
Regards,
Lucy

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
Sent: Tuesday, November 17, 2015 12:50 PM
To: Henderickx, Wim (Wim); EXT - 
thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi,

I think Wim has conclusively demonstrated that this draft has fatal flaws and I 
don’t support it.  I also agree with his suggestion that we first figure out 
what problem we are trying to solve before solving it.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 12:49 PM
To: EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?


2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes

I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you so

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Henderickx, Wim (Wim)]

Lucy, does not change anything but I did a typo
I meant to say every tenant needs a different VXLAN UDP destination port for 
upstream + receive port for downstream on NVE

From: Lucy yong mailto:lucy.y...@huawei.com>>
Date: Tuesday 17 November 2015 at 11:54
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
"thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>, BESS 
mailto:bess@ietf.org>>
Subject: RE: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

For this to work every tenant needs a different VXLAN UDP destination 
port/receive port.

[Lucy] this is not right. For the traffic from DC ASBR -> NVE, only one UDP dst 
port is used; for the traffic from NVE-> DC ASBR, DC ASBR signaled UDP port 
number will be used. Tenant traffic is segregated by VNID, not UDP port. At an 
NVE, the traffic going toward the same remote PE will be encapsulated w/ VXLAN 
and the same UDP dst port number even the traffic may belong to different VNs. 
In short, tenant and UDP port are orthogonal; the solution just uses UDP port 
to indicate the outgoing mpls label for the packets at DC ASBR when it receives 
packets from NVEs.

Lucy

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 11:49 AM
To: thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?




2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes


I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming

Re: [bess] AD Review of draft-ietf-bess-mvpn-extranet-03

[Eric C Rosen]

On 11/12/2015 2:50 PM, Alvaro Retana (aretana) wrote:

Hi!

I just finished reading this document.


[Eric]  Alvaro, thanks for your review.  I just posted revision -04, 
with a number of edits made in response to your comments.



As mentioned by the WG chairs at the meeting in Yokohama, the technology
in bess can be complex and hard to penetrate for the average (or novice)
reader.  While the target of documents like this one is not always the
average (or novice) reader, it is important that those readers
(including the IESG and other review directorates) are able to at least
understand what's going on.


[Eric] Often, reviewers from various directorates are assigned documents
that they are not qualified to review.  This is certainly a problem, but 
not a problem with the documents.  There is also a problem with certain 
ADs (NOT routing area ADs of course) who don't know nearly as much as 
they think they do.  Well, luckily for them, bidirectional multicast is 
not discussed in this document, as it really seems to freak them out!



Because of the length of the document, it would be nice to include a
"road map" to guide the reader (in general: "Section x talks about X,
Section y covers Y, etc.").  It might be easier to include references to
the specific sections in 1.4 (Overview).


[Eric]  I think the table of contents is as good a road map as we are 
going to get.  Adding additional pointers to the overview doesn't 
provide additional value, and most likely would just introduce errors.


This is a long standards track document, so it is bound to have a lot of
normative language.  On one hand I don't want to go overboard with
explicitly mandating every little step..but at the same time we want to
be clear as to what is "actually required for interoperation or to limit
behavior which has potential for causing harm" [RFC2119].  Due to the
potential of bad configurations resulting in incomplete/illdefined
extranets, I can see why the behavior around RTs would require normative
language.  However, there are some places where the use of rfc2119
keywords may be lacking, not needed or inconsistent.  An example of
inconsistency is this paragraph from Section 7.2.3.1. (When Inter-Site
Shared Trees Are Used):

If VRF-S exports a Source Active A-D route that contains C-S in the
Multicast Source field of its NLRI, and if that VRF also exports a
UMH-eligible route matching C-S, the Source Active A-D route MUST
carry at least one RT in common with the UMH-eligible route.  The RT
must be chosen such that the following condition holds: if VRF-R
contains an extranet C-receiver allowed by policy to receive extranet
traffic from C-S, then VRF-R imports both the UMH-eligible route and
the Source Active A-D route.

.. If the "route MUST carry at least one RT", why isn't the condition to
be met also normative?  I don't want to belabor on this specific case,
it is just an example.


[Eric] I think you are right about this case; I've fixed the text.


However, I would appreciate it if the authors
would scan the document for required or unneeded normative language.  I
pointed at some cases in my comments below.


[Eric] I looked at each of the 200 or so occurrences of "must", 
"should", etc., and made some changes.  I think it's more consistent 
now, but the criteria for when to say "MUST" and when to say "must" have 
never been very clear.



I do have a couple of items that I think are Major (see below) that I
would like to see addressed before starting the IETF Last Call.



Major:

 1. Section 1.3. (Clarification on Use of Route Distinguishers) uses the
word "REQUIREs" in a couple of places.  In a strict manner, the
rfc2119 key words is "REQUIRED".  While I think that the meaning of
using "REQUIREs" should be obvious, please rephrase the text to
strictly use the rfc2119 language.


[Eric]  I changed "this document REQUIREs" to "it is REQUIRED by this
document".  Hopefully, the RFC editor won't ding me for unnecessary use
of the passive voice ;-)


 2. Section 10 (Security Considerations)
  * What is a "VPN security violation"?  It is mentioned in several
places, but it is not explicitly defined.  Please either add a
reference or be clear in what it is.


[Eric] A "VPN security violation" is just any situation in which a
packet gets delivered to a VPN where it isn't supposed to go.  I added a
definition in the terminology section, and also in the Security
Considerations section.


  * Misconfiguration is a significant risk, for example assigning
the wrong RTs to the wrong routes.  I think that risk should be
mentioned.


[Eric] This is generally true of any technology based upon RFC4364.  I
added a sentence about this to the Security Considerations.


Minor:

 1. Section 1.1. (Terminology): "We will sometimes say that a route
"matches" a particular host if the route matches an IP address of
the host."  Given the previous definiti

[bess] I-D Action: draft-ietf-bess-mvpn-extranet-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the BGP Enabled Services Working Group of the 
IETF.

Title   : Extranet Multicast in BGP/IP MPLS VPNs
Authors : Yakov Rekhter
  Eric C. Rosen
  Rahul Aggarwal
  Yiqun Cai
  Thomas Morin
Filename: draft-ietf-bess-mvpn-extranet-04.txt
Pages   : 61
Date: 2015-11-17

Abstract:
   Previous RFCs specify the procedures necessary to allow IP multicast
   traffic to travel from one site to another within a BGP/MPLS IP VPN
   (Virtual Private Network).  However, it is sometimes desirable to
   allow multicast traffic whose source is in one VPN to be received by
   systems that are in another VPN.  This is known as a "Multicast VPN
   (MVPN) extranet".  This document updates RFCs 6513, 6514, and 6625 by
   specifying the procedures that are necessary in order to provide MVPN
   extranet service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-extranet/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-mvpn-extranet-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-mvpn-extranet-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

Hi John,

I don’t know what is the fatel flaw here. The solution works. It is matter of 
the preference. Even if the way of UDP port proposed in the draft is not 
acceptable, we can use IP addresses to achieve it. The key is that BESS WG 
needs option C solution for the use case that the applications  are contexts 
where overlays are present is when workloads (VMs or baremetal) need to be 
interconnected with VPNs. In these contexts, there can be reasons to want 
Option C to reduce the state on ASBRs.

Regards,
Lucy

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of John E Drake
Sent: Tuesday, November 17, 2015 12:50 PM
To: Henderickx, Wim (Wim); EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi,

I think Wim has conclusively demonstrated that this draft has fatal flaws and I 
don’t support it.  I also agree with his suggestion that we first figure out 
what problem we are trying to solve before solving it.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 12:49 PM
To: EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?



2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes

I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you something else in mind ?

WH> see ab

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Lucy yong]

For this to work every tenant needs a different VXLAN UDP destination 
port/receive port.

[Lucy] this is not right. For the traffic from DC ASBR -> NVE, only one UDP dst 
port is used; for the traffic from NVE-> DC ASBR, DC ASBR signaled UDP port 
number will be used. Tenant traffic is segregated by VNID, not UDP port. At an 
NVE, the traffic going toward the same remote PE will be encapsulated w/ VXLAN 
and the same UDP dst port number even the traffic may belong to different VNs. 
In short, tenant and UDP port are orthogonal; the solution just uses UDP port 
to indicate the outgoing mpls label for the packets at DC ASBR when it receives 
packets from NVEs.

Lucy

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 11:49 AM
To: thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?




2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes


I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you something else in mind ?

WH> see above. The draft right now also requires changes in existing TOR/NVE so 
for me all this discussion/debate is void.

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible eno

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[John E Drake]

Hi,

I think Wim has conclusively demonstrated that this draft has fatal flaws and I 
don’t support it.  I also agree with his suggestion that we first figure out 
what problem we are trying to solve before solving it.

Yours Irrespectively,

John

From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of Henderickx, Wim (Wim)
Sent: Tuesday, November 17, 2015 12:49 PM
To: EXT - thomas.mo...@orange.com; BESS
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?




2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes


I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you something else in mind ?

WH> see above. The draft right now also requires changes in existing TOR/NVE so 
for me all this discussion/debate is void.

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support?

WH> and depending on implementation you don’t need to change any of the 
TOR/vswitches.

Does this mean that for some implementations you may not need to change any of 
the TOR/vswitches, but that for some others you may ?

WH> any proposal on the table requires changes, so for me this is not a valid 
d

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Henderickx, Wim (Wim)]

— Snip —

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support? For this to work 
every tenant needs a different VXLAN UDP destination port/receive port.
There might be SW elements that could do some of this, but IETF defines 
solutions which should be implemented across the board HW/SW/etc. Even if some 
SW switches can do this, the proposal will impose so many issues in 
HW/data-plane engines that I cannot be behind this solution.

To make this work generically we will have to make changes anyhow. Given this, 
we better do it in the right way and guide the industry to a solution which 
does not imply those complexities. Otherwise we will stick with these specials 
forever with all consequences (bugs, etc).

- snip -

From: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Tuesday 17 November 2015 at 01:37
To: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>, 
BESS mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):

2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe requirements, but 
the current proposal I cannot agree to for the reasons explained.

TM> Well, although discussing forever is certainly not the goal, the reasons 
for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN data-plane 
here, the use cases I have seen in this txt is always where an application 
behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements.


My understanding is that the applications  are contexts where overlays are 
present is when workloads (VMs or baremetal) need to be interconnected with 
VPNs. In these contexts, there can be reasons to want Option C to reduce the 
state on ASBRs.

In these context, its not the workload (VM or baremetal) that would typically 
handle VRFs, but really the vswitch or ToR.

WH2> can it not be all cases: TOR/vswitch/Application. I would make the 
solution flexible to support all of these not?



2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in 
this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to support 
MPLS/MPLS/(UDP or GRE)

WH> b depends on the use case

I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application behind NVE/TOR 
requiring model C, than all the discussion on impact on NVE/TOR is void. As 
such I want to have a discussion on the real driver/requirement for option c 
interworking with an IP based Fabric.

Although I can agree than detailing requirements can always help, I don't think 
one can assume a certain application to dismiss the proposal.

WH> for me the proposal is not acceptable for the reasons explained: too much 
impact on the data-planes

I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or 
GRE), which hence has to be supported on the ToRs and vswitches.
Another possibility would be service-label/middle-label/Ethernet assuming an L2 
adjacency between vswitches/ToRs and ASBRs, but this certainly does not match 
your typical DC architecture. Or perhaps had you something else in mind ?

WH> see above. The draft right now also requires changes in existing TOR/NVE so 
for me all this discussion/debate is void.

No, the spec as it is can be implemented in its VXLAN variant with existing 
vswitches (e.g. OVS allows to choose the VXLAN destination port, ditto for the 
linux kernel stack).

(ToR is certainly another story, most of them not having a flexible enough 
VXLAN dataplane nor support for any MPLS-over-IP.)

WH> and how many ports simultaneously would they support?

WH> and depending on implementation you don’t need to change any of the 
TOR/vswitches.

Does this mean that for some implementations you may not need to change any of 
the TOR/vswitches, but that for some others you may ?

WH> any proposal on the table requires changes, so for me this is not a valid 
discussion

See above, the proposal in the draft does not necessarily need changes in 
vswitches.


Let me take a practical example : while I can quite easily see how to implement 
the procedures in draft-hao-bess-inter-nvo3-vpn-optionc based on current 
vswitch implementations of VXLAN, the lack of MPLS/MPLS/(UDP, GRE) support in 
commonplace vswitches seems to me as making that alternate solution you suggest 
harder to implement.

WH> I would disagree to this. Tel

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[thomas.morin]

Hi Wim, WG,

2015-11-16, Henderickx, Wim (Wim):


2015-11-13, Henderickx, Wim (Wim):
Thomas, we can discuss forever and someone need to describe 
requirements, but the current proposal I cannot agree to for the 
reasons explained.


TM> Well, although discussing forever is certainly not the goal, the 
reasons for rejecting a proposal need to be thoroughly understood.
WH> my point is what is the real driver for supporting a plain VXLAN 
data-plane here, the use cases I have seen in this txt is always where 
an application behind a NVE/TOR is demanding option c, but none of the 
NVE/TOR elements.




My understanding is that the applications  are contexts where overlays 
are present is when workloads (VMs or baremetal) need to be 
interconnected with VPNs. In these contexts, there can be reasons to 
want Option C to reduce the state on ASBRs.


In these context, its not the workload (VM or baremetal) that would 
typically handle VRFs, but really the vswitch or ToR.




2015-11-13, Henderickx, Wim (Wim):

TM> The right trade-off to make may in fact depend on whether you prefer:
(a) a new dataplane stitching behavior on DC ASBRs (the behavior 
specified in this draft)
or (b) an evolution of the encaps on the vswitches and ToRs to 
support MPLS/MPLS/(UDP or GRE)


WH> b depends on the use case


I don't get what you mean by "b depends on the use case".
WH> see my above comment. If the real use case is an application 
behind NVE/TOR requiring model C, than all the discussion on impact on 
NVE/TOR is void. As such I want to have a discussion on the real 
driver/requirement for option c interworking with an IP based Fabric.


Although I can agree than detailing requirements can always help, I 
don't think one can assume a certain application to dismiss the proposal.





I wrote the above based on the idea that the encap used in 
MPLS/MPLS/(UDP or GRE), which hence has to be supported on the ToRs 
and vswitches.
Another possibility would be service-label/middle-label/Ethernet 
assuming an L2 adjacency between vswitches/ToRs and ASBRs, but this 
certainly does not match your typical DC architecture. Or perhaps had 
you something else in mind ?


WH> see above. The draft right now also requires changes in existing 
TOR/NVE so for me all this discussion/debate is void.


No, the spec as it is can be implemented in its VXLAN variant with 
existing vswitches (e.g. OVS allows to choose the VXLAN destination 
port, ditto for the linux kernel stack).


(ToR is certainly another story, most of them not having a flexible 
enough VXLAN dataplane nor support for any MPLS-over-IP.)




WH> and depending on implementation you don’t need to change any of 
the TOR/vswitches.


Does this mean that for some implementations you may not need to 
change any of the TOR/vswitches, but that for some others you may ?


WH> any proposal on the table requires changes, so for me this is not 
a valid discussion


See above, the proposal in the draft does not necessarily need changes 
in vswitches.




Let me take a practical example : while I can quite easily see how to 
implement the procedures in draft-hao-bess-inter-nvo3-vpn-optionc 
based on current vswitch implementations of VXLAN, the lack of 
MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to me as 
making that alternate solution you suggest harder to implement.


WH> I would disagree to this. Tell me which switch/TOR handles 
multiple UDP ports for VXLAN ?


I mentioned _v_switches, and many do support a variable destination port 
for VXLAN, which is sufficient to implement what the draft proposes.


-Thomas













From: Thomas Morin 
Organization: Orange
Date: Friday 13 November 2015 at 09:57
To: Wim Henderickx 
Cc: "bess@ietf.org" 
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

I agree on the analysis that this proposal is restricted to 
implementations that supports the chosen encap with non-IANA ports 
(which may be hard to achieve for instance on hardware 
implementations, as you suggest), or to context where managing 
multiple IPs would be operationally viable.


However, it does not seem obvious to me how the alternative you 
propose [relying on 3-label option C with an MPLS/MPLS/(UDP|GRE) 
encap] addresses the issue of whether the encap behavior is 
supported or not (e.g. your typical ToR chipset possibly may not 
support this kind of encap, and even software-based switches may not 
be ready to support that today).


My take is that having different options to adapt to various 
implementations constraints we may have would have value.


(+ one question below on VXLAN...)

-Thomas


2015-11-12, Henderickx, Wim (Wim):
On VXLAN/NVGRE, do you challenge the fact that they would be used 
with a dummy MAC address that would be replaced by the right MAC 
by a sender based on an ARP request when needed ?


Is the above the issue you had in mind about VXLAN and NVGRE ?

WH> yes


I you don't mind me asking : why do you challenge that ?









__

Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

[Haoweiguo]

Hi Wim,

WH> I first want to understand the requirements for this use case and I don’t 
agree to adoption since there are major DP implications in this.
[weiguo]: You proposed MPLS over GRE/UDP encapsulation for the traffic between 
data center inside and outside MPLS VPN network. However, for some TOR 
switches, they don't support MPLS Over GRE/UDP. Even if they support, they rely 
on internal loop and the forwarding performance will be reduced half.  For 
option-c scenario, TOR switches need to realize MPLS+MPLS+GRE/UDP, it's more 
complicated for TOR switches. Current most of the TOR switches support VXLAN 
encapsulation and have no half forwarding performance issue.  For ASBR-d, it is 
router device in most case, it has capability to realize more comlicated 
forwarding behavior.

Thanks,
weiguo

From: BESS [bess-boun...@ietf.org] on behalf of Henderickx, Wim (Wim) 
[wim.henderi...@alcatel-lucent.com]
Sent: Tuesday, November 17, 2015 0:52
To: Thomas Morin; bess@ietf.org
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

In-line

From: Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>
Date: Monday 16 November 2015 at 08:29
To: Thomas Morin mailto:thomas.mo...@orange.com>>, 
"bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc



From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Thomas Morin mailto:thomas.mo...@orange.com>>
Organization: Orange
Date: Monday 16 November 2015 at 07:47
To: "bess@ietf.org" 
mailto:bess@ietf.org>>, Wim Henderickx 
mailto:wim.henderi...@alcatel-lucent.com>>
Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc

Wim,

Henderickx, Wim (Wim) :
VXLAN has a dedicated UDP port and is very clear in the RFC7348

Well, having a port reserved for this use that won't be the default for another 
protocol is one thing, but that does not prevent in itself the same protocol to 
be applied on another range of ports. (Because HTTP specs says port 80 does not 
prevent the URI scheme to allow specifying the port in the URL)

Even reading the VXLAN (Informational) specs, we see room for flexibility wrt 
ports:

  -  Destination Port: IANA has assigned the value 4789 for the
 VXLAN UDP port, and this value SHOULD be used by default as the
 destination UDP port.  Some early implementations of VXLAN have
 used other values for the destination port.  To enable
 interoperability with these implementations, the destination
 port SHOULD be configurable.

I read "4789 SHOULD be used by default" and "SHOULD be configurable".

WH> true but it does not say to use multiple at the same time. My read on this 
is that it allows a non standard port to be used, but not multiple at the same 
time.




Will write something on what I proposed when I get some time, not soon

The co-chair in me needs to ask the following question: should this call for 
adoption be kept on hold until an outline of an alternative solution is 
provided ?

WH> I first want to understand the requirements for this use case and I don’t 
agree to adoption since there are major DP implications in this.


-Thomas






From: Lucy yong 
<lucy.y...@huawei.com>
Date: Friday 13 November 2015 at 17:10
To: Wim Henderickx 
<wim.henderi...@alcatel-lucent.com>,
 Haoweiguo mailto:haowei...@huawei.com>>
Cc: "bess@ietf.org" 
mailto:bess@ietf.org>>
Subject: RE: draft-hao-bess-inter-nvo3-vpn-optionc

Hi Wim,

OptionC is very useful for DCI use case. In this case, multi-hop EBGP 
redistributes VN routes between the end NVEs in source and destination Ass, 
ASBRs do not maintain and distribute the VN routes; a tunnel is built between 
the end NVEs in source and destination Ass for traffic transport. Due to the 
different data planes in DC and WAN, the tunnel is stitched by several 
segments, IP tunnels are used in DCs, and MPLS tunnels are used in WAN.

Traditional OptionC requires end-to-end MPLS, which may fit to some DCI cases. 
However, there are many DCs that do not support MPLS data plane. This draft is 
to provide the solution for this use case.

Although VXLAN has UDP port number, if tunnel ingress and egress can negotiate 
to use another UDP port for the VXLAN encapsulation, I don’t see it breaks 
anything. Not sure if hw has this restriction either. Even yes, we can consider 
using UDP source port for this purpose. UDP source port is used for transit 
ECMP and filled by flow entropy, tunnel egress can determine the flow entropy 
value and inform tunnel ingress. Thus, tunnel egress (i.e. DC ASBR) can 
maintain UDP source port and MPLS label table; when DC ASBR receives a packet 
from NVE, by lookup the table, it gets the label for the packet, push the label 
on the packet before send