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

Jeffrey Haas <jhaas@pfrc.org> Wed, 18 December 2019 20:27 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F4120C17; Wed, 18 Dec 2019 12:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqBVjV-566sk; Wed, 18 Dec 2019 12:27:16 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 33457120C15; Wed, 18 Dec 2019 12:27:16 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 174961E2F6; Wed, 18 Dec 2019 15:31:46 -0500 (EST)
Date: Wed, 18 Dec 2019 15:31:45 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>, "draft-ietf-bfd-vxlan@ietf.org" <draft-ietf-bfd-vxlan@ietf.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>
Subject: Re: =?iso-8859-1?Q?=C9ric_Vyncke's_Discus?= =?iso-8859-1?Q?s?= on draft-ietf-bfd-vxlan-09: (with DISCUSS and COMMENT)
Message-ID: <20191218203145.GD6488@pfrc.org>
References: <157657269782.26511.12421406428553874826.idtracker@ietfa.amsl.com> <CED2B858-AC55-4B0A-ADA2-AC46B628E6DA@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CED2B858-AC55-4B0A-ADA2-AC46B628E6DA@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/BMW8_RKVJMSUa0Q8LMx9inVe83o>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 20:27:18 -0000

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 <noreply@ietf.org<mailto:noreply@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 ?
> 
> 
>