Hi, Jeff,
The TTL of 1 recommended for RFC 4379 / RFC 8029 S4.3 is because if the MPLS
packet is mis-routed, or there's a forwarding mis-programming, then an MPLS LSE
pop would expose the BFD packet and so that the BFD is not further
mis-forwarded.
In the VXLAN case an intermediate router would not remove the VXLAN encap
because the outer encap is IP (with a destination address, not an MPLS Label
that can be mis-interpreted in context) and a mid-point router would not
understand VXLAN.
Thanks,
Carlos.
2019/12/18 午後3:27 に、"Jeffrey Haas" <jh...@pfrc.org> を書き込みました:
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 ?
>
>
>
