Re: Opsdir last call review of draft-ietf-bfd-vxlan-07
On Tue, Jun 04, 2019 at 01:40:13PM -0700, Greg Mirsky wrote: > Hi Jurgen, > thank you for your review, detailed and precise questions. Please find my > answers in-line and tagged GIM>>. > > Regards, > Greg > > On Tue, May 21, 2019 at 12:28 AM Jürgen Schönwälder via Datatracker < > nore...@ietf.org> wrote: > > > Reviewer: Jürgen Schönwälder > > Review result: Has Issues > > > > I only have a very limited understanding of VXLAN ands BFD technology.. > > Hence, some of my question may look odd to the insiders. > > > > - RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be > > standards track? > > > GIM>> That has been somewhat of the way to bring the de-facto standard into > the IETF standardization process. I leave this to the IESG. > - Section 2.1 "Terminology" expands acronyms but it does say where > > these "terms" are actually defined. Some pointers to the relevant > > RFCs may be useful. > > > GIM>> That might be useful, thank you. But, AFAIK, at IETF that is not the > traditional format (though I know that other SDOs refer to the source of > the definition used in the document.) Perhaps conventions different between different parts of the IETF, as a review, I find it helpful to know where things are actually defined (and I assume the same is true for implementors). > > - I am not familiar with VXLAN but I wonder how the endpoints > > addresses are obtained in practice. This BFD document says for > > example "The details of how the MAC address of the destination VTEP > > is obtained are outside the scope of this document." Well, OK, but > > how does this work? Is there a document where this is explained? > > Well, I am actually less concerned about how the inner address is > > obtained, I think I am more urgently missing how the VTEP determines > > the remote tunnel endpoint address. > > > GIM>> One of the ways could be through exchange of the BFD packets when the > DA MAC is the dedicated MAC. More on that below. > > > > > - Why do you need a special MAC address? The text says I can use this > > address or the address of the destination VTEP but there is no > > reasoning when to use what or why a dedicated address is needed. > > > GIM> Would the following text added at the end of Section 4.1 address your > question: > NEW TEXT: > The use of the dedicated MAC allows starting BFD session before > learning the MAC address of the remote VTEP. As a result, after the > BFD session has reached the Up state the operational state of the > VXLAN tunnel to may be set to Up. Not sure I managed to parse the second sentence. So is the idea that the dedicated MAC address is only do be used until the MAC address has been discovered? But yes, any text that helps readers to understand this is appreciated. > > - What is a 'reasonable upper bound' on the number of BFD sessions > > that can be created between the same pair of VTEPs? 1? 2? 8? 64? > > 256? 4096? How does the choice of this upper bound impact security? > > > GIM>> I agree, that is too vague. Would changing the text to recommend > that the control mechanism be provided if multiple BFD sessions between the > same piar of VTEP allowed: > OLD TEXT: >The implementation SHOULD have a reasonable upper bound on the number >of BFD sessions that can be created between the same pair of VTEPs. > NEW TEXT: >If the implementation supports establishing multiple BFD sessions >between the same pair of VTEPs, there SHOULD be a mechanism to control >the maximum number of such session that can be active at the same >time. Works for me. I read this as "the maximum number of such session should be configurable", which is great advice for implementors. > > - Which BFD mode is assumed to be used, asynchronous or demand? Or > > does this not matter for this usage of BFD, i.e., both work just > > fine and will be interoperable? > > > GIM>> For p2p VXLAN tunnel, the Asynchronous mode of BFD is recommended: > The asynchronous mode of BFD, as defined in [RFC5880], >can be used to monitor a p2p VXLAN tunnel. > The Demand mode is used in RFC 8293 that is recommended if the Multicast > Service Node resides behind the NVE: >In the case where a Multicast Service Node (MSN) (as described in >Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms >described in this document apply and can, therefore, be used to test > the connectivity from the source NVE to the MSN. Perhaps say more explicitely that in the Multicast Service Node case, demand mode of BFD is
Re: Yangdoctors last call review of draft-ietf-bfd-yang-09
On Sun, Mar 04, 2018 at 02:12:30PM +, Reshad Rahman (rrahman) wrote: > > We have made the changes in revs 10 and 11 to address your comments . The > exception is module ietf-bfd-types which did not get renamed per reason below. > Hi, here is my re-review of draft-ietf-bfd-yang. I think the document has significantly improved since the -09 version, the authors have done an excellent job to improve the document quality. I have mostly a few minor mostly editorial issues left, except the first one, which concerns the schema mount use case. - Thanks for clarifying that the modules can be used on standalone devices. The new text is helpful. For the LNE and NI use cases, does it make sense to detail the mount points that are used? My understanding is that schema mount requires that mount points are identified with a "mount-point" extension statement, i.e., you can't mount at arbitrary places in the hierarchy but only at places that have been designated as mount points. That all said, since your YANG modules are basically augmenting other YANG modules that may be mounted, you do not seem to need a separate schema mount. If my understanding is correct, then here is a starting point for making this clearer: OLD When used at the network device level, the BFD YANG model is used "as-is". When the BFD model is to be used in a Logical Network Element or in a Network Instance, the approach taken is to do a schema-mount (see Schema Mount [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate location. For example, if an implementation supports BFD IP multihop in network instances, the implementation would do schema-mount of the BFD IP multihop model in a mount-point which resides in a network instance. NEW When used at the network device level, the BFD YANG model are used "as-is". When the BFD YANG model is used in a Logical Network Element or in a Network Instance, then the BFD YANG model augments the mounted routing model for the Logical Network Element or the Network Instance. Note that with this change, you also do not need a reference to schema mount. - Since the different use cases (device, LNE, NI) are discussed right at the beginning of Section 2, it seems the following statements in Sections 2.5, 2.6, 2.7, 2.8, 2.9 are not really needed: The "bfd" node under control-plane- protocol can be used in a network device (top-level), or mounted in an LNE or in a network instance. The "ip-sh" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. The "ip-mh" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. The "lag" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. The "mpls" node can be used in a network device (top-level), or mounted in an LNE or in a network instance. - The text at the beginning of Section 2.13 should also mention RFC 8177 since you are importing it. - It might be useful to give more explicit instructions to IANA. I assume you want IANA to update the iana-bfd-types module whenever changes are made to the "BFD Diagnostic Codes" registry and "BFD Authentication Types" registries. Giving clear instructions what IANA is expected to do and when is better than a soft statement such as "intended to reflect". But IANA is going to ask questions about this anyway during their review I assume. - The feature definitions in ietf-bfd-types have text of the form "as defined in RFC 5880" and perhaps it makes sense to add reference statements to these feature definitions. There are also a number of identities that say "as per RFC 588X" where perhaps reference statements should be added. - The text at the beginning of Section 2.13 should also mention RFC 6991 since you are importing it. And you are also importing from RFC (the routing model). - The text at the beginning of Section 2.16 should also mention that you import from RFC (the routing model). - The text at the beginning of Section 2.17 should also mention that you import from RFC 6991 and from RFC (the routing model). - The text at the beginning of Section 2.18 should also mention that you import from RFC (the routing model). - The text at the beginning of Section 2.19 should also mention that you import from RFC (the routing model). - I have not validated the examples - I hope the authors have done so. They look more plausible than in the pre
Re: [yang-doctors] Yangdoctors last call review of draft-ietf-bfd-yang-09
On Fri, Feb 16, 2018 at 11:11:28PM +, Acee Lindem (acee) wrote: > * Design of the Data Model > > - Do I always have to use schema mount to use these YANG models? If > so, one might consider I-D.ietf-netmod-schema-mount a normative > reference. Are you not augmenting the routing model? > > This Is definitely not the case. This model will augment RFC8022BIS. The > question on how to do is being discussion on the YANG doctors list. > This is what I thought but the text is kind of misleading: BFD can operate in the following contexts: [...] The approach taken is to do a schema-mount (see Schema Mount [I-D.ietf-netmod-schema-mount]) of the BFD model in the appropriate locations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
