Hi Xiao Min, Can you provide more detail on your scenario? I'm having trouble figuring it out from the description below. I need to know what subnets the tenants are in.
Anoop On Thu, Oct 10, 2019 at 5:00 AM <[email protected]> wrote: > Hi Anoop, > > > Please see my response inline with [XM]. > 原始邮件 > *发件人：*AnoopGhanwani <[email protected]> > *收件人：*肖敏10093570; > *抄送人：*[email protected] <[email protected]>; > [email protected] <[email protected]>;rtg-bfd WG <[email protected]>; > *日 期 ：*2019年10月10日 15:47 > *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP* > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > Hi Xiao Min, > > In those cases, the term "VN" is used to talk about multiple IP interfaces > in a VRF. The different interfaces would have to be different VNIs. > > [XM] To be clear, I interpret VNI as Virtual Network Identifier that > should be present within VxLAN/Geneve header. Do you mean in the case > multiple Tenant Systems connect to multiple NVEs through IP routing > network, different NVEs must encapsulate different Virtual Network > Identifiers? > > In the mixed case (with MPLS and L2 hitting the NVE at different VAPs), > I'm not sure how it would work in the same VNI. If you think it's > important, I think it may be worth writing it up. If there's enough merit > in the use case, we can figure out how to run multiple BFD sessions on the > same VNI. > > [XM] As to the mixed case, I don't know whether there's enough merit, I > just raise it for discussion because it seems not being prohibited from the > NVO3 architecture point of view. > > > Anoop > > > Best Regards, > > Xiao Min > > > On Wed, Oct 9, 2019 at 11:06 PM <[email protected]> wrote: > >> Hi Anoop, >> >> >> Normally, it is. While Tenant Systems connect to NVE through IP routing >> network or MPLS forwarding network, it is not. >> >> >> Best Regards, >> >> Xiao Min >> 原始邮件 >> *发件人：*AnoopGhanwani <[email protected]> >> *收件人：*肖敏10093570; >> *抄送人：*[email protected] <[email protected]>; >> [email protected] <[email protected]>;rtg-bfd WG <[email protected]>; >> *日 期 ：*2019年10月10日 05:33 >> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP* >> Hi Xiao Min, >> Normally, I think of a VNI as a broadcast domain. The only way I can >> make sense of the picture below is to have a separate VNI for each MPLS >> interface on the NVE. >> >> Anoop >> >> On Tue, Oct 8, 2019 at 11:09 PM <[email protected] >> <[email protected]>> wrote: >> >>> Hi Anoop, >>> >>> >>> In this use case there is no forwarding happens between the MPLS and >>> non-MPLS parts, would this use case be prohibited? >>> >>> If the answer is yes, then I agree that all Tenant Systems attached to a >>> common NVE MUST share a VAP so long as they connect to the same VN, >>> although in RFC8014 it uses "can" but not "MUST". As a result, we should >>> not allow multiple BFD sessions for the same VNI between two NVEs. >>> >>> If the answer is no, then we should allow multiple BFD sessions for the >>> same VNI between two NVEs. I personally lean to this answer. >>> >>> >>> Best Regards, >>> >>> Xiao Min >>> 原始邮件 >>> *发件人：*AnoopGhanwani <[email protected]> >>> *收件人：*肖敏10093570; >>> *抄送人：*Greg Mirsky <[email protected]>;[email protected] < >>> [email protected]>;[email protected] < >>> [email protected]>;[email protected] <[email protected]>; >>> [email protected] <[email protected]> < >>> [email protected]>;rtg-bfd WG <[email protected]>;Joel M. >>> Halpern <[email protected]>;[email protected] <[email protected]>; >>> *日 期 ：*2019年10月09日 06:28 >>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP* >>> Hi Xiao Min, >>> The picture doesn't have enough information to explain why they are in >>> the same VNI, and exactly how forwarding happens between the MPLS and >>> non-MPLS parts. >>> >>> Anoop >>> >>> On Tue, Oct 8, 2019 at 12:31 AM <[email protected]> wrote: >>> >>>> Hi Anoop, >>>> >>>> >>>> I don't know such a draft that describes MPLS over Geneve, but I >>>> believe the following figure derived from figure 1 of RFC8014 would help, >>>> in the following figure Tenant System1, Tenant System2, Tenant System3 and >>>> Tenant System4 are assumed belonging to the same VNI, so two BFD sessions >>>> for the same VNI need to be run between NVE1 and NVE2. >>>> >>>> +--------+ >>>> +----| Tenant | >>>> ( ' ) | System1| >>>> ................ ( MPLS ) +--------+ >>>> . . +--+-+ ( _ ) >>>> . .--|NVE1|---+ >>>> . . | | >>>> . . +--+-+ >>>> . . | >>>> . L3 Overlay . ( ' ) >>>> . Network . (Ethernet) >>>> . . ( _ ) >>>> . . | >>>> ................ +--------+ >>>> | | Tenant | >>>> +----+ | System2| >>>> |NVE2| +--------+ >>>> | |--------+ >>>> +----+ | >>>> | | >>>> ( ' ) ( ' ) >>>> ( MPLS ) (Ethernet) >>>> ( _ ) ( _ ) >>>> | | >>>> +--------+ +--------+ >>>> | Tenant | | Tenant | >>>> | System3| | System4| >>>> +--------+ +--------+ >>>> >>>> >>>> Best Regards, >>>> >>>> Xiao Min >>>> 原始邮件 >>>> *发件人：*AnoopGhanwani <[email protected] <[email protected]>> >>>> *收件人：*肖敏10093570; >>>> *抄送人：*Greg Mirsky <[email protected]>;[email protected] >>>> <[email protected]> <[email protected]>;[email protected] < >>>> [email protected]>;[email protected] <[email protected]>; >>>> [email protected] <[email protected]>;rtg-bfd WG >>>> <[email protected]>;Joel M. Halpern <[email protected]>; >>>> [email protected] <[email protected]>; >>>> *日 期 ：*2019年10月08日 12:15 >>>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP* >>>> Hi Xiao Min, >>>> Is there a draft that describes MPLS over Geneve? It sounds like the >>>> NVE is an MPLS router in this case and if you're using the same VNI as you >>>> switch MPLS, then it's a one-armed router. That doesn't change how BFD >>>> needs to be run between NVEs. >>>> >>>> Anoop >>>> >>>> On Mon, Oct 7, 2019 at 7:28 PM <[email protected]> wrote: >>>> >>>>> Hi Anoop, >>>>> >>>>> >>>>> Sorry for the late response, I just come back from vacation. >>>>> >>>>> The use case is that the network between the VM and the NVE is an MPLS >>>>> network, within which the packet is forwarded basing on MPLS label, but >>>>> not >>>>> Ethernet MAC address and/or 802.1Q VLAN. When two such kind of MPLS >>>>> networks need to communicate with each other, through a Geneve tunnel, the >>>>> encap I illustrated would be used. >>>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Xiao Min >>>>> 原始邮件 >>>>> *发件人：*AnoopGhanwani <[email protected]> >>>>> *收件人：*肖敏10093570; >>>>> *抄送人：*Greg Mirsky <[email protected]>;[email protected] < >>>>> [email protected]>;[email protected] < >>>>> [email protected]>;[email protected] <[email protected]>; >>>>> [email protected] <[email protected]>;rtg-bfd >>>>> WG <[email protected]>;Joel M. Halpern <[email protected] >>>>> <[email protected]>>;[email protected] <[email protected]>; >>>>> *日 期 ：*2019年09月28日 05:36 >>>>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at >>>>> VTEP* >>>>> Hi Xiao Min, >>>>> Thanks for the details about the encap but the use case is not clear. >>>>> It might help if you explain why its necessary to map a physical Ethernet >>>>> port and/or 802.1Q VLAN to the same VNI as an MPLS packet without an L2 >>>>> header. >>>>> >>>>> Thanks, >>>>> Anoop >>>>> >>>>> On Thu, Sep 26, 2019 at 7:50 PM <[email protected]> wrote: >>>>> >>>>>> Hi Anoop, >>>>>> >>>>>> >>>>>> Due to the fact that a variety of Tunnels could be used under the >>>>>> NVO3 architecture, as an example, below figure illustrates the >>>>>> format of MPLS packet over Geneve Tunnel. >>>>>> >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> ~ Outer Ethernet Header ~ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> ~ Outer IPvX Header ~ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> ~ Outer UDP Header ~ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> ~ Geneve Header ~ >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ >>>>>> | | | >>>>>> ~ MPLS Label Stack ~ M >>>>>> | | P >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L >>>>>> | | S >>>>>> | | >>>>>> ~ Payload ~ P >>>>>> | | K >>>>>> | | T >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+ >>>>>> | FCS | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> >>>>>> >>>>>> Note that in NVO3 working group Greg and I have submitted an >>>>>> individual draft draft-xiao-nvo3-bfd-geneve, which is used to address BFD >>>>>> over Geneve. >>>>>> >>>>>> The intention is to make the two drafts draft-ietf-bfd-vxlan and >>>>>> draft-xiao-nvo3-bfd-geneve aligned, that is to say, we try to define the >>>>>> identical mechanism for the common part of BFD over VxLAN Tunnel and BFD >>>>>> over Geneve Tunnel. For the common part, draft-xiao-nvo3-bfd-geneve would >>>>>> reference to draft-ietf-bfd-vxlan, and for the other part specific to >>>>>> Geneve, we'll define the specific mechanism in >>>>>> draft-xiao-nvo3-bfd-geneve. >>>>>> >>>>>> >>>>>> Hope that clarifies. >>>>>> >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Xiao Min >>>>>> 原始邮件 >>>>>> *发件人：*AnoopGhanwani <[email protected]> >>>>>> *收件人：*肖敏10093570; >>>>>> *抄送人：*Greg Mirsky <[email protected]>;[email protected] >>>>>> <[email protected]> <[email protected]>;[email protected] >>>>>> <[email protected]>;[email protected] <[email protected]>; >>>>>> [email protected] <[email protected]>;rtg-bfd >>>>>> WG <[email protected]>;Joel M. Halpern <[email protected]>; >>>>>> [email protected] <[email protected] <[email protected]>>; >>>>>> [email protected] <[email protected]>; >>>>>> *日 期 ：*2019年09月26日 23:16 >>>>>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at >>>>>> VTEP* >>>>>> Hi Xiao Min, >>>>>> I think we would need more detail around the use case below. What >>>>>> does the MPLS packet over Tunnel look like? >>>>>> >>>>>> Thanks, >>>>>> Anoop >>>>>> >>>>>> On Wed, Sep 25, 2019 at 11:37 PM <[email protected]> wrote: >>>>>> >>>>>>> Hi Anoop, >>>>>>> >>>>>>> >>>>>>> Thanks for your comments. >>>>>>> >>>>>>> Considering a scenario where TS1 has an MPLS access (i.e. >>>>>>> MPLS-Packet over Tunnel between NVEs) to VNI1, TS3 has an Ethernet >>>>>>> access >>>>>>> (i.e. MAC-Frame over Tunnel between NVEs) to VNI1, then how can TS1 and >>>>>>> TS3 >>>>>>> share one VAP? >>>>>>> >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Xiao Min >>>>>>> 原始邮件 >>>>>>> *发件人：*AnoopGhanwani <[email protected]> >>>>>>> *收件人：*肖敏10093570; >>>>>>> *抄送人：*Greg Mirsky <[email protected]>;[email protected] < >>>>>>> [email protected]>;[email protected] < >>>>>>> [email protected]>;[email protected] <[email protected]>; >>>>>>> [email protected] <[email protected]>;rtg-bfd >>>>>>> WG <[email protected]>;Joel M. Halpern <[email protected]>; >>>>>>> [email protected] <[email protected]>;[email protected] < >>>>>>> [email protected]>; >>>>>>> *日 期 ：*2019年09月26日 08:36 >>>>>>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at >>>>>>> VTEP* >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>>> >>>>>>> >>> >>>>>>> Some people may argue that all Tenant Systems connecting to the same >>>>>>> Virtual Network MUST share one VAP, if that's true, then VAP1 and VAP3 >>>>>>> should merge into one VAP and my explanation doesn't work. Copying to >>>>>>> NVO3 >>>>>>> WG to involve more experts, hope for your clarifications and comments. >>>>>>> >>> >>>>>>> >>>>>>> I would be one of those that would argue that they MUST share on VAP >>>>>>> if they connect to the same Virtual Network. IMO, the NVO3 arch doc >>>>>>> should >>>>>>> have been clearer about this. >>>>>>> >>>>>>> Thanks, >>>>>>> Anoop >>>>>>> >>>>>>> On Tue, Sep 24, 2019 at 7:40 PM <[email protected]> wrote: >>>>>>> >>>>>>>> Hi Santosh, >>>>>>>> >>>>>>>> >>>>>>>> With regard to the question whether we should allow multiple BFD >>>>>>>> sessions for the same VNI or not, IMHO we should allow it, more >>>>>>>> explanation >>>>>>>> as follows... >>>>>>>> >>>>>>>> Below is a figure derived from figure 2 of RFC8014 (An >>>>>>>> Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) >>>>>>>> ). >>>>>>>> >>>>>>>> | Data Center Network (IP) | >>>>>>>> | | >>>>>>>> +-----------------------------------------+ >>>>>>>> | | >>>>>>>> | Tunnel Overlay | >>>>>>>> +------------+---------+ +---------+------------+ >>>>>>>> | +----------+-------+ | | +-------+----------+ | >>>>>>>> | | Overlay Module | | | | Overlay Module | | >>>>>>>> | +---------+--------+ | | +---------+--------+ | >>>>>>>> | | | | | | >>>>>>>> NVE1 | | | | | | >>>>>>>> NVE2 >>>>>>>> | +--------+-------+ | | +--------+-------+ | >>>>>>>> | |VNI1 VNI2 VNI1 | | | | VNI1 VNI2 VNI1 | | >>>>>>>> | +-+-----+----+---+ | | +-+-----+-----+--+ | >>>>>>>> |VAP1| VAP2| | VAP3 | |VAP1| VAP2| | VAP3| >>>>>>>> +----+-----+----+------+ +----+-----+-----+-----+ >>>>>>>> | | | | | | >>>>>>>> | | | | | | >>>>>>>> | | | | | | >>>>>>>> -------+-----+----+-------------------+-----+-----+------- >>>>>>>> | | | Tenant | | | >>>>>>>> TSI1 | TSI2| | TSI3 TSI1| TSI2| |TSI3 >>>>>>>> +---+ +---+ +---+ +---+ +---+ +---+ >>>>>>>> |TS1| |TS2| |TS3| |TS4| |TS5| |TS6| >>>>>>>> +---+ +---+ +---+ +---+ +---+ +---+ >>>>>>>> >>>>>>>> To my understanding, the BFD sessions between NVE1 and NVE2 are >>>>>>>> actually initiated and terminated at VAP of NVE. >>>>>>>> >>>>>>>> If the network operator want to set up one BFD session between VAP1 >>>>>>>> of NVE1 and VAP1of NVE2, at the same time another BFD session between >>>>>>>> VAP3 >>>>>>>> of NVE1 and VAP3 of NVE2, although the two BFD sessions are for >>>>>>>> the same VNI1, I believe it's reasonable, so that's why I think we >>>>>>>> should allow it. >>>>>>>> >>>>>>>> >>>>>>>> Of course, in RFC8014 it also says: >>>>>>>> >>>>>>>> "Note that two different Tenant Systems (and TSIs) attached to a >>>>>>>> common NVE can share a VAP (e.g., TS1 and TS2 in Figure 2) so long as >>>>>>>> they connect to the same Virtual Network." >>>>>>>> >>>>>>>> Some people may argue that all Tenant Systems connecting to the >>>>>>>> same Virtual Network MUST share one VAP, if that's true, then VAP1 and >>>>>>>> VAP3 >>>>>>>> should merge into one VAP and my explanation doesn't work. Copying to >>>>>>>> NVO3 >>>>>>>> WG to involve more experts, hope for your clarifications and comments. >>>>>>>> >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Xiao Min >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> _______________________________________________ >>> nvo3 mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >> >> >
