Hi Dinesh, many thanks for your time, the expertise you've kindly shared on this discussion. I believe that Santosh has volunteered ;) to provide some text on the firewall interaction. Any other contributions are welcome and greatly appreciated.
Regards, Greg On Wed, Oct 23, 2019 at 3:54 PM Dinesh Dutt <did...@gmail.com> wrote: > Looks good to me Greg. I see that the text around the use of the inner IP > address as also quite acceptable. Will you add any words about the firewall? > > Dinesh > > On Wed, Oct 23, 2019 at 8:36 PM, Greg Mirsky <gregimir...@gmail.com> > wrote: > > Hi Dinesh, et al., > please check the updated version that removed the reference to Hypervisor > in the text and Figure 1. > > Regards, > Greg > > On Wed, Oct 23, 2019 at 10:47 AM Santosh P K <santosh.pallaga...@gmail.com> > wrote: > >> Dinesh, >> Please see my inline comments [SPK] >> >>> >>> - In section 3, there's a sentence that is: "BFD packets intended for a >>> Hypervisor VTEP MUST NOT..". I recommend getting rid of the word >>> "Hypervisor" ashe logic applies to any VTEP. >>> >>> [SPK] Thanks for comments. We will change this. >> >> >>> - You already explained the precedence of the use of 127/8 address in >>> the inner header in MPLS. I have no specific comments in that area. I have >>> only two questions: >>> - Has anybody verified that the use of 127/8 address (and the right >>> MAC) works with existing implementations, including the silicon ones? If >>> this doesn't work there, is it worth adding the possibilit y of another >>> address, one that is owned by the VTEP node? >>> >> - Do we know if Firewalls stop such VXLAN packets? I ask this because >>> VXLAN has an IP header and I don't know if firewalls stop packets with >>> 127/8 in the inner header. If not, is it worth adding a sentence to say >>> that firewalls allow such packets? The use of a non-127/8 address may >>> alleviate this case as well. >>> >> >> [SPK] I think we may need to add the text about firewall as some checks >> in firewall will be there if they are not already using MPLS OAM which has >> inner IP header with 127/8 address range. >> >> >>> >>> The rest of the draft looks good to me, >>> >>> Dinesh >>> >>> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <gregimir...@gmail.com> >>> wrote: >>> >>> Hi Dinesh, >>> I greatly appreciate your comments. Please heave a look at the attached >>> copy of the working version and its diff to -07 (latest in the datatracker). >>> >>> Regards, >>> Greg >>> >>> On Tue, Oct 22, 2019 at 9:52 PM Dinesh Dutt <did...@gmail.com> wrote: >>> >>>> I have the same feeling as Anoop. Greg, can you please point me to the >>>> latest draft so that I can quickly glance through it to be doubly sure, >>>> >>>> Dinesh >>>> >>>> On Wed, Oct 23, 2019 at 4:35 AM, Anoop Ghanwani <an...@alumni.duke.edu> >>>> wrote: >>>> >>>> Greg, >>>> >>>> I think the draft is fine as is. >>>> >>>> I discussion with Xiao Min was about #3 and I see that as unnecessary >>>> until we have a draft that explains why that is needed in the context of >>>> the NVO3 architecture. >>>> >>>> Anoop >>>> >>>> On Tue, Oct 22, 2019 at 11:17 AM Greg Mirsky <gregimir...@gmail.com> >>>> wrote: >>>> >>>>> Hi Anoop, et al., >>>>> I agree with your understanding of what is being defined in the >>>>> current version of the BFD over VxLAN specification. But, as I understand, >>>>> the WG is discussing the scope before the WGLC is closed. I believe there >>>>> are three options: >>>>> >>>>> 1. single BFD session between two VTEPs >>>>> 2. single BFD session per VNI between two VTEPs >>>>> 3. multiple BFD sessions per VNI between two VTEPs >>>>> >>>>> The current text reflects #2. Is WG accepts this scope? If not, which >>>>> option WG would accept? >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Oct 22, 2019 at 2:09 PM Anoop Ghanwani <an...@alumni.duke.edu> >>>>> wrote: >>>>> >>>>>> I concur with Joel's assessment with the following clarifications. >>>>>> >>>>>> The current document is already capable of monitoring multiple VNIs >>>>>> between VTEPs. >>>>>> >>>>>> The issue under discussion was how do we use BFD to monitor multiple >>>>>> VAPs that use the same VNI between a pair of VTEPs. The use case for >>>>>> this >>>>>> is not clear to me, as from my understanding, we cannot have a situation >>>>>> with multiple VAPs using the same VNI--there is 1:1 mapping between VAP >>>>>> and >>>>>> VNI. >>>>>> >>>>>> Anoop >>>>>> >>>>>> On Tue, Oct 22, 2019 at 6:06 AM Joel M. Halpern <j...@joelhalpern.com> >>>>>> wrote: >>>>>> >>>>>>> From what I can tell, there are two separate problems. >>>>>>> The document we have is a VTEP-VTEP monitoring document. There is >>>>>>> no >>>>>>> need for that document to handle the multiple VNI case. >>>>>>> If folks want a protocol for doing BFD monitoring of things behind >>>>>>> the >>>>>>> VTEPs (multiple VNIs), then do that as a separate document. The >>>>>>> encoding will be a tenant encoding, and thus sesparate from what is >>>>>>> defined in this document. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 10/21/2019 5:07 PM, Jeffrey Haas wrote: >>>>>>> > Santosh and others, >>>>>>> > >>>>>>> > On Thu, Oct 03, 2019 at 07:50:20PM +0530, Santosh P K wrote: >>>>>>> >> Thanks for your explanation. This helps a lot. I would wait >>>>>>> for more >>>>>>> >> comments from others to see if this what we need in this draft to >>>>>>> be >>>>>>> >> supported based on that we can provide appropriate sections in >>>>>>> the draft. >>>>>>> > >>>>>>> > The threads on the list have spidered to the point where it is >>>>>>> challenging >>>>>>> > to follow what the current status of the draft is, or should be. >>>>>>> :-) >>>>>>> > >>>>>>> > However, if I've followed things properly, the question below is >>>>>>> really the >>>>>>> > hinge point on what our encapsulation for BFD over vxlan should >>>>>>> look like. >>>>>>> > Correct? >>>>>>> > >>>>>>> > Essentially, do we or do we not require the ability to permit >>>>>>> multiple BFD >>>>>>> > sessions between distinct VAPs? >>>>>>> > >>>>>>> > If this is so, do we have a sense as to how we should proceed? >>>>>>> > >>>>>>> > -- Jeff >>>>>>> > >>>>>>> > [context preserved below...] >>>>>>> > >>>>>>> >> Santosh P K >>>>>>> >> >>>>>>> >> On Wed, Sep 25, 2019 at 8:10 AM <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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nvo3 mailing list >>>>>>> n...@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>>> >>>>>>
