Carlos, Éric, Note that I'm not an expert in the underlying MPLS technologies. I'll make two notes:
BFD for vxlan is in a similar feature-space as RFC 5884, BFD for MPLS. RFC 5884, section 7, paragraph 3, suggests a TTL of 1 and provides a reference to RFC 4379. RFC 4379, section 4.3, provides procedures for TTL of 1. My personal inference would be that implementations at least in MPLS-land really want the TTL to be 1 for purposes of doing appropriate encapsulation checks. I agree that GTSM procedures would suggest we may want TTL of 255. I suggest the answer we're looking for here would be provided by parties with appropriate history on why RFC 4379 recommends its procedures. Failing that, I suspect BFD for vxlan is no worse than 4379. -- Jeff On Tue, Dec 17, 2019 at 05:17:11PM +0000, Carlos Pignataro (cpignata) wrote: > Hi, Éric, > > Regarding you first DISCUSS element, I had brought up the same issue. See the > 2nd point at > https://mailarchive.ietf.org/arch/msg/rtg-bfd/BL9Ob66Yxie4wX13yZJELbYPLJs > > Thanks, > > Carlos. > > 2019/12/17 午前3:51、Éric Vyncke via Datatracker > <nore...@ietf.org<mailto:nore...@ietf.org>>のメール: > > Éric Vyncke has entered the following ballot position for > draft-ietf-bfd-vxlan-09: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > Thank you for the work put into this document. > > I fully second Adam's COMMENT that should be fixed before publication (IMHO > this is a DISCUSS). > > Answers to my COMMENTs below will be welcome, even if those COMMENTs are not > blocking. > > As usual, an answer to the DISCUSS is required to clear my DISCUSS though. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == DISCUSS == > > May be I am not familiar enough with BFD, but, RFC 5881 (the one defining BFD) > specifies the use of TTL = Hop Limit = 255.. Why this document uses a value of > 1 ? > > -- Section 3 -- > IPv4-mapped IPv6 addresses are only to be used inside a host and should never > be transmitted in real packets (including packets inside a tunnel) see section > 4.2 of RFC 4038 (even if informational). As other IESG reviewers, I wonder why > ::1/128 is not used? > > -- Section 8 -- > The document specifies no IANA actions while the shepherd write-up talks about > a IANA action. > > -- Section 9 -- > This section is only about IPv4 (TTL and RFC 1812). Please address IPv6 as > well. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > == COMMENTS == > > RFC 5881 (BFD) states that it applies to IPv4/IPv6 tunnels, may I infer that > this document is only required to address the Ethernet encapsulation ? I.e. > specifying the Ethernet MAC addresses? > > -- Section 3 -- > At first sight, I was surprized by having a BFD session per VXLAN VNI as it > will create some scalability issue, but, I assume that this is to detect > misconfiguration as well. If so, perhaps worth mentionnig the reasoning > behind? > > In "the inner destination IP address SHOULD" it is unclear whether it is in > the > all BFD packets, or only the request one or ... ? > > -- Section 4 -- > While probably defined in RFC7348, should "FCS" be renamed as "Outer Ethernet > FCS" for consistency with the "Outer Ethernet Header" in figure 2 ? > > Why not using the Source MAC address as the Destination MAC address ? This > would ensure that there is no conflict at the expense of "forcing" the > transmission of the frame even if addressed to itself. > > Please consider rewriting the section about TTL/Hop Limit as it is not easy to > parse/read. > > -- Section 9 -- > It is unclear to me (see also Ben's comment) what is the 'attack vector' of > sending packets with TTL=1 ? > > >
