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 <xiao.m...@zte.com.cn> 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 <an...@alumni.duke.edu> > *收件人：*肖敏10093570; > *抄送人：*Greg Mirsky <gregimir...@gmail.com>;did...@gmail.com < > did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org < > draft-ietf-bfd-vx...@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>; > santosh.pallaga...@gmail.com <santosh.pallaga...@gmail.com>;rtg-bfd WG < > rtg-...@ietf.org>;Joel M. Halpern <j...@joelhalpern.com>; > tsrid...@vmware.com <tsrid...@vmware.com>; > *日 期 ：*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 <xiao.m...@zte.com.cn> 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 <an...@alumni.duke.edu> >> *收件人：*肖敏10093570; >> *抄送人：*Greg Mirsky <gregimir...@gmail.com>;did...@gmail.com < >> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org < >> draft-ietf-bfd-vx...@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>; >> santosh.pallaga...@gmail.com <santosh.pallaga...@gmail.com>;rtg-bfd WG < >> rtg-...@ietf.org>;Joel M. Halpern <j...@joelhalpern.com>; >> tsrid...@vmware.com <tsrid...@vmware.com>; >> *日 期 ：*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 <xiao.m...@zte.com.cn> 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 <an...@alumni.duke.edu> >>> *收件人：*肖敏10093570; >>> *抄送人：*Greg Mirsky <gregimir...@gmail.com>;did...@gmail.com < >>> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org < >>> draft-ietf-bfd-vx...@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>; >>> santosh.pallaga...@gmail.com <santosh.pallaga...@gmail.com>;rtg-bfd WG < >>> rtg-...@ietf.org>;Joel M. Halpern <j...@joelhalpern.com>; >>> tsrid...@vmware.com <tsrid...@vmware.com>;bfd-cha...@ietf.org < >>> bfd-cha...@ietf.org>; >>> *日 期 ：*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 <xiao.m...@zte.com.cn> 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 <an...@alumni.duke..edu> >>>> *收件人：*肖敏10093570; >>>> *抄送人：*Greg Mirsky <gregimir...@gmail.com>;did...@gmail.com < >>>> did...@gmail.com>;draft-ietf-bfd-vx...@ietf.org < >>>> draft-ietf-bfd-vx...@ietf.org>;nvo3@ietf.org <nvo3@ietf.org>; >>>> santosh.pallaga...@gmail.com <santosh.pallaga...@gmail.com>;rtg-bfd WG >>>> <rtg-...@ietf.org>;Joel M. Halpern <j...@joelhalpern.com>; >>>> tsrid...@vmware.com <tsrid...@vmware.com>;bfd-cha...@ietf.org < >>>> bfd-cha...@ietf.org>; >>>> *日 期 ：*2019年09月26日 08:36 >>>> *主 题 ：**Re: [nvo3] BFD over VXLAN: Trapping BFD Control packet at VTEP* >>>> _______________________________________________ >>>> nvo3 mailing list >>>> nvo3@ietf.org >>>> 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 <xiao.m...@zte.com.cn> 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 nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
