> > > One more comment for section 3.1 Inner to Outer Address Mapping. The > destination inner**** > > > address here, I think refer to destination IP/MAC address. But from my > view, this is**** > > > a bit narrow concept. A flow to outer address mapping would be a more > general concept.**** > > > The flow could be defined with any fields in the packet header.**** > > ** ** > > I think you’re right about that, although the language to express it will > need to be written with care. > [Lizhong] yes, in practice, the fields like DPORT, SPORT, flow label, protocol number and etc could be used to do classification.
> **** > > ** ** > > If a remote NVE has multiple addresses, this additional classification > based on non-address fields in the packet may make sense to separate > traffic by more than destination address, e.g., put different sorts of > traffic into separate tunnels to the same NVE where the tunnels use > different network infrastructure or otherwise get treated differently by > the underlay. OTOH, it should not be the case that the location for > ultimate delivery of the encapsulated traffic depends on non-address fields > in the packet header.**** > > ** ** > > The simple case for the latter is that for a given NVE, the same > destination address maps to the same remote NVE (although that remote NVE > might vary over time, e.g., due to failover). I’m not at all sure about > tackling association of a TS w/multiple NVEs for the same virtual network > in a fashion that allows encapsulate traffic for the same overlay > destination to be sent via more than one remote NVE. > [Lizhong] in the case of TS multihoming to two NVEs, if loadbalancing and active-active is required (similar with the active-active in EVPN), and if you want to do controlled loadbalancing, then different flow (with same dest address) could be classified to different NVE. > **** > > ** ** > > Thanks, > --David**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Lizhong Jin > *Sent:* Monday, July 01, 2013 11:22 AM > *To:* [email protected]; Benson Schliesser > *Subject:* Re: [nvo3] Poll for WG Adoption of > draft-kreeger-nvo3-overlay-cp-04**** > > ** ** > > Hi all,**** > > Yes, support. There is two comments as below.**** > > ** ** > > Fast acquisition of needed state. For example, when a Tenant System emits > a packet destined to an inner address that the NVE does not have a mapping > for, the NVE should be able to acquire the needed mapping quickly.**** > > [Lizhong] a mechanism should be provided to let NVE know whether the > required mapping is existed on NVA or not. If the required mapping is not > existed, special action could be applied (e.g, drop packet) to avoid > accessing NVA.**** > > ** ** > > One more comment for section 3.1 Inner to Outer Address Mapping. The > destination inner address here, I think refer to destination IP/MAC > address. But from my view, this is a bit narrow concept. A flow to outer > address mapping would be a more general concept. The flow could be defined > with any fields in the packet header.**** > > ** ** > > Regards**** > > Lizhong**** > > ** ** > > **** > > > > ---------- Forwarded message ---------- > From: Benson Schliesser <[email protected]> > To: "[email protected]" <[email protected]> > Cc: > Date: Thu, 27 Jun 2013 21:25:48 -0400 > Subject: [nvo3] Poll for WG Adoption of draft-kreeger-nvo3-overlay-cp-04 > This email begins a two week poll to help the chairs judge if there is > consensus to adopt draft-kreeger-nvo3-overlay-cp-04 as an NVO3 working > group draft. > > Please respond to this email on the list with 'support' or 'do not > support'. > > Please also send any comments on the draft to the NVO3 list. > > We are also polling for knowledge of any IPR that applies to this draft, > to ensure that IPR has been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor, please respond to > this email whether or not you are aware of any relevant IPR. The draft will > not be adopted until a response has been received from each author and > contributor. > > If you are on the NVO3 WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > This poll closes on 11 July 2013. > > Cheers, > -Benson & Matthew > > > **** > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
