Hi Ben, many thanks for your comments, suggestions and the discussions. These helped a lot in making the better document. Please find my notes in response to your comments below under the GIM>> tag.
Regards, Greg On Tue, Sep 29, 2020 at 1:31 PM Benjamin Kaduk via Datatracker < nore...@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bfd-vxlan-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-vxlan/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the discussions around my discuss point, and the ensuing > changes > resulting from the discussions! My apologies that I was tardy in > re-reviewing after > the updates were made. > > I think the core issues have been resolved, but do have a couple comments > on the -14: > > Section 3 says: > > Separate BFD sessions can be established between the > VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 > and 200). Using a BFD session to monitor a set of VXLAN VNIs between > the same pair of VTEPs might help to detect and localize problems > caused by misconfiguration. An implementation that supports this > specification MUST be able to control the number of BFD sessions that > can be created between the same pair of VTEPs. [...] > > While the first two sentences are probably true, they are arguably out > of scope for this document, since Section 6 says that BFD control > packets on non-management VNI is outside the scope of this > specification. GIM>> Yes, the document describes applicability of BFD over the Management VNI. Procedures described in the document might work for non-managemnt VNIs but the document doesn't make any assumption about that. And that is why a case of non-management VNI was set outside the scope of the specification. > The third sentence is quite surprising in the context of > this document only defining BFD for the management VNI, since multiple > BFD sessions on the same VNI seem redundant. > GIM>> True. The intention was to suggest that if an implementation may be used on non-management VNIs, then the number of concurrent BFD sessions must be controlled. I think that it is unlikely that there will be a document that will define BFD over VXLAN for non-managemet VNIs and developers may appreciate some guidance this document provides. > > Section 5 > > Destination MAC: A Management VNI, which does not have any > tenants, will have no dedicated MAC address for decapsulated > traffic. The value [TBD1] SHOULD be used in this field. > > While this normative language seems like the appropriate level of > stringency, I do find myself wondering what other value might be used > and why. (This, of course, need not be answered in the document, though > it could be if the answer is known and useful.) > GIM>> There are early implementations that have been deployed that use other MAC values. We might disagree with their choice but wanted to allow thier conformance to this specification.
