Anoop, I guess there were multiple discussion over this should we have inner TTL as 1 or destination IP address as 127/8 range so that if packet gets exposed in underlay it should not be routed via underlay to VTEP.
Thanks Santosh P K On Wed, Oct 23, 2019 at 11:40 AM Anoop Ghanwani <[email protected]> wrote: > Hi Greg, > > The part about the use of 127/8 address appears to be a new thing > introduced in the version of the draft that is as of yet unpublished. What > was the motivation for the change? Previously, the DA was simply set to > the destination VTEP's IP address which seemed fine. > > Anoop > > On Tue, Oct 22, 2019 at 7:48 PM Dinesh Dutt <[email protected]> wrote: > >> Greg, >> >> Two comments, one minor and one maybe not. >> >> - 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. >> >> - 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. >> >> The rest of the draft looks good to me, >> >> Dinesh >> >> On Wed, Oct 23, 2019 at 7:58 AM, Greg Mirsky <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[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 >>>>>> >>>>>> _______________________________________________ >>>>>> nvo3 mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/nvo3 >>>>>> >>>>>
