Re: Éric Vyncke's Discuss on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>のメール:
> 
> É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 ?
> 
> 
>