[nvo3] 答复: Follow up on draft-tissa-nvo3-oam-fm

[Haoweiguo <[e-mail]>]

Hi Tissa,

I think this draft is very similar to TRILL OAM framework. The entropy data in TRILL OAM is for flow-based load balancing to ensure OAM packet forwarding same path
as detected data packet in ECMP case.
For NVO3 network, flow-based load balancing relies on NVO3 outer header,so this entropy data has no any use for load balancing.

In hierarchical NVO3 network scenario, the interworking gateway gateway relies on destination NVE IP
address and source UDP port(or GRE key) to make the ECMP path selection, if the source UDP port is allocated in random mode on interworking
gateway, the entropy data can be used for the gateway to acquire source UDP port(in VXLAN case) and destination NVE IP. But if ingress NVE knows the Udp port on interworking gateway in beforehand, it can carry the information in OAM TLV message directly instead of entropy data.



thanks

weiguo

________________________________
发件人: Tissa Senevirathne (tsenevir) [[e-mail]]
发送时间: 2014年3月4日 3:55
收件人: David Allan I; [e-mail]
主题: Re: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

Hi David

Please see in-line

From: David Allan I [mailto:[e-mail]]
Sent: Monday, March 03, 2014 8:50 AM
To: Tissa Senevirathne (tsenevir); [e-mail]
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:


Thanks for the response and raising a  very important point.

At GW NVE , we need L3 information to select the NVE on the L3 cloud to forward the packet.

Yes. And a GW would need to examine the client payload of frames received from “x-space” to determine the L3 destination of interest in “y-space”. And encode the relevant entropy in the overlay header to permit multipath. Easiest approach for such a GW would be to be able to copy the entropy from the received overlay header.  Same would apply in the reverse direction. So the GWs appear as VTEPs in x-space and in Y-space in the role of next hops to whomever….

[Tissa] What is the definition of Entropy in the above ? especially in the context “able to copy the entropy from the received overlay header…”

Originator NVE has to use the GW Dest IP (GW NVE address) i.e. Packet on  (x space)  use Dest IP of NVEGW and packet on (y space) use Dest NVE B. NVE GW has to make a lookup on the payload to get NVEB address. We will have multiple NVE on the B space.


++++++       ( x space  )          +++++++++++     (y space)                 +++++++++
| NVEA|---------------------- | NVE GW   |  ------------------------ |NVE B     |
++++++                                   +++++++++++                                       +++++++++

If needed we can quickly discuss face to face too, please let me know

That there is a problem is not leaping out at me. You’re going to have to clarify. Is this a shortcoming in the drafts?

Cheers
Dave

From: David Allan I [mailto:[e-mail]]
Sent: Monday, March 03, 2014 8:17 AM
To: Tissa Senevirathne (tsenevir); [e-mail]<mailto:[e-mail]>
Subject: RE: Follow up on draft-tissa-nvo3-oam-fm

HI Tissa:

My understanding of at least one of the proposed NVO3 encaps (VxLAN), is that the entropy has already been encoded in the source port. I would assume any L3 VNI encap would require a similar property for ECMP to perform useful load spreading as ECMP would only examine the outer header.

So the information to utilize distributed gateways would already exist, and sufficient information exists for OAM to fate share in a trail that spanned an L2 and L3 VNI. N’est pas?

That’s the view from here!
Dave

From: nvo3 [mailto:[e-mail]] On Behalf Of Tissa Senevirathne (tsenevir)
Sent: Monday, March 03, 2014 4:02 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [nvo3] Follow up on draft-tissa-nvo3-oam-fm

There was a question on why payload sample is needed in OAM.

Firstly it is an optional field and not always required.

It is expected to be useful when using L2VNI + L3VNI at the same NVE to provide L3 gateway services to clients on L2VNI. Reference is draft-ietf-nvo3-dataplane-requirements-02, section 3.2.2 second last paragraph, please see below section for reference. At the L2VNI/L3VNI GW the sample payload is needed to make the ECMP path selection on the next domain (i.e L3VNI when L2VNI to L3VNI and vise versa).

Reference second last paragraph of section 3.2.2 of draft-ietf-nvo3-dataplane-requirements-02
“       L2 and L3 VNIs can be deployed in isolation or in combination to
       optimize traffic flows per tenant across the overlay network. For
       example, an L2 VNI may be configured across a number of NVEs to
       offer L2 multi-point service connectivity while a L3 VNI can be co-
       located to offer local routing capabilities and gateway
       functionality. In addition, integrated routing and bridging per
       tenant MAY be supported on an NVE. An instantiation of such service
       may be realized by interconnecting an L2 VNI as access to an L3 VNI
       on the NVE.”