[mpls] Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi, Eric et al.,
I've updated relevant drafts, draft-ietf-mpls-p2mp-bfd and
draft-ietf-nvo3-geneve-oam, to use an address from the new IPv6 Associated
Channel IPv6 range as the destinatination address of the inner IP/UDP
encapsulation of active OAM packets. I attached two diffs that highlight
all updates applied to these drafts. Below, please find details of these
changes:

   - draft-ietf-mpls-p2mp-bfd
      - A new section as part of IANA Considerations:

7.1.  IPv6 Address Allocation

   IANA is requested to allocate an IPv6 TBA2/64 prefix as Associated
   Channel IPv6 Prefix in the "Internet Protocol Version 6 Address
   Space" and add the prefix to the "IANA IPv6 Special Purpose Address
   Registry".

   - Updated Abstract as follows:

OLD TEXT:
   Furthermore, this document also updates RFC 8562 and recommends the
   use of an IPv6 loopback address (::1/128) and discourages the use of
   an IPv4 loopback address mapped to IPv6.
NEW TEXT:
   Furthermore, this document also updates RFC 8562 and recommends the
   use of an IPv6 from the Associated Channel IPv6 range TBA2/64 and
   discourages the use of an IPv4 loopback address mapped to IPv6.

   - Updated Introduction:

OLD TEXT:
   Historically, an IPv6-mapped IPv4 loopback range
   address::ffff:127.0.0.1/128 was mandated, although functionally, an
   IPv6 address from that range is not analogous to its IPv4
   counterpart.  This draft starts the transition to using the proper
   IPv6 loopback address as the IPv6 destination address in the IP/UDP
   encapsulation of active OAM over the MPLS data plane.  Thus, this
   document also updates [RFC8562] and recommends the use of an IPv6
   loopback address (::1/128) while acknowledging that an address from
   ::ffff:127.0.0.1/128 range might be used by existing implementations,
   discourages the use of the IPv6-mapped IPv4 loopback range address.
NEW TEXT:
   Historically, an IPv6-mapped IPv4 loopback range
   address::ffff:127.0.0.1/128 was mandated, although functionally, an
   IPv6 address from that range is not analogous to its IPv4
   counterpart.  Furthermore, using the loopback address as the
   destination address even for an inner IP encapsulation of a tunneled
   packet violates Section 2.5.3 of [RFC4291].  Hence, IANA is requested
   to allocate TBA2/64 range as a new Associated Channel IPv6 Prefix
   range that can be used for selecting destination IPv6 addresses for
   IP/UDP encapsulation of management, control, and OAM packets.  This
   draft starts the transition to using the IPv6 addresses from the
   Associated Channel IPv6 Prefix range as the IPv6 destination address
   in the IP/UDP encapsulation of active OAM over the MPLS data plane.
   Thus, this document also updates [RFC8562] and recommends the use of
   an IPv6 address from the Associated Channel IPv6 Prefix range TBA2/64
   (Section 7.1) while acknowledging that an address from
   ::ffff:127.0.0.1/128 range might be used by existing implementations,
   discourages the use of the IPv6-mapped IPv4 loopback range address.

   - Also, updated Section 3.1:

OLD TEXT:
   *  [RFC4291] defines a single IPv6 loopback address.  Hence, for
      IPv6, the IPv6 loopback address ::1/128 SHOULD be used.
NEW TEXT:
   *  The sender of an MPLS echo request SHOULD use an address from the
      Associated Channel IPv6 Prefix range TBA2/64 Section 7.1.


   - draft-ietf-nvo3-geneve-oam
      - Updated Section 2.3:

OLD TEXT:
   Inner IP header:

      Destination IP: The IP address MUST be set to the loopback address
      127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6
      [RFC4291].
NEW TEXT:
   Inner IP header:

      Destination IP: The IP address MUST be set to the loopback address
      127.0.0.1/32 for IPv4 version.  For IPv6, the address MUST be
      selected from the Associated Channel IPv6 Range for IPv6
      [I-D.ietf-mpls-p2mp-bfd].

   - Added as the Normative reference:

   [I-D.ietf-mpls-p2mp-bfd]
              Mirsky, G., Mishra, G. S., and D. E. Eastlake,
              "Bidirectional Forwarding Detection (BFD) for Multipoint
              Networks over Point-to-Multi-Point MPLS Label Switched
              Path (LSP)", Work in Progress, Internet-Draft, draft-ietf-
              mpls-p2mp-bfd-09, 6 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
              p2mp-bfd-09>.

I greatly appreciate your thoughtful and constructive suggestions. I hope
that I captured the esseintail parts and got us closer to the acceptable
resolution.

Regards,
Greg

On Tue, Jan 14, 2025 at 9:35 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Greg,
>
>
>
> This is indeed one way (or the other way round of course) as I wrote in a
> different email earlier today :-)
>
>
>
> -éric
>
>
>
>
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Tuesday, 14 January 2025 at 17:01
> *To: *Gunter van de Velde (Nokia) <[e-mail]>
> *Cc: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>,
> [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>, NVO3 <[e-mail]>, [e-mail]
> <[e-mail]>, [e-mail] <
> [e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08:
> (with DISCUSS and COMMENT)
>
> Hi Eric and Gunter,
>
> thank you for your guidance. I thought of using draft-ietf-mpls-p2mp-bfd
> to request the IANA allocation. Consequently, draft-ietf-nvo3-geneve-oam
> will require using the proper IPv6 addresses and have the Normative
> reference in that regard to draft-ietf-mpls-p2mp-bfd. Would that be an
> acceptable way forward?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jan 14, 2025 at 8:58 AM Gunter van de Velde (Nokia) <
> [e-mail]> wrote:
>
> Thank you for the follow up Eric,
>
>
>
> At least from draft-ietf-nvo3-geneve-oam perspective a fresh LC seems
> appropriate.
>
>
>
> The sequencing of events depends upon which draft Greg wants to use to get
> the IANA IP address related code-points. Greg, would you have an early
> insight on how you prefer to progress?
>
>
>
> G/
>
>
>
> *From:* Eric Vyncke (evyncke) <evyncke=[e-mail]>
> *Sent:* Tuesday, January 14, 2025 2:50 PM
> *To:* Greg Mirsky <[e-mail]>; The IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; NVO3 <
> [e-mail]>; [e-mail]; [e-mail]
> *Subject:* Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08:
> (with DISCUSS and COMMENT)
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Greg,
>
>
>
> I am perfectly fine with option #2 (even if option #3 is nicer from my INT
> AD point of view), i.e., one I-D is requesting the IPv4/IPv6 prefixes with
> the right wording in its IANA section and the other I-D has some text about
> re-using those prefixes with a normative reference to the 1st I-D (plus
> some notes to the RFC editor to copy the selected prefixes).
>
>
>
> Now, these two I-Ds are in the routing area, so, it is also up to the RTG
> ADs to express their preferences and decide whether a new IETF Last Call is
> required (as this is an important technical change in the I-Ds).
>
>
>
> I understand that this is more work for many people and some delays, but
> the final I-Ds will be much more elegant and no more violating RFC 4291 😊
> Hence, I will clear my DISCUSS position.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Friday, 10 January 2025 at 23:14
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail]
> <[e-mail]>, NVO3 <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, Bocci, Matthew (Nokia - GB) <
> [e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08:
> (with DISCUSS and COMMENT)
>
> Hi Eric,
>
> Thank you for the detailed explanation of all options to conclude the work
> of two WGs on these documents properly. I think that Option #2 is
> reasonable and will work on updating drafts accordingly. In the meantime, I
> appreciate your thoughts on where to request IANA. Would it be acceptable
> if such a request is expressed in one document, e.g.,
> draft-ietf-mpls-p2mp-bfd, and the other document uses a Normative reference
> to that draft? If that is acceptable, we will avoid any possibility of
> duplication of the IANA part.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Jan 10, 2025 at 2:36 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
> Greg,
>
>
>
> Thank you for merging the two threads, very sensible action as the two
> IETF drafts have the same issue.
>
>
>
> The IESG discussed it during the 9th of January telechat, and there are
> at least three solutions (all allowing for ECMP probing):
>
>
>
> 1.      Using the 100::/64 prefix (as you wrote it was not published when
> the original RFC were published), easy, immediate solution for IPv6, but
> not for IPv4
>
> 2.      The MPLS/NVO3 drafts add an IANA section requesting an IPv6 /64
> prefix and an IPv4 /24 prefix for this specific use (with a note about
> avoiding duplicates), similar future documents could then refer to either
> the MPLS/NVO3 RFC
>
> 3.      A short/quick (AD-sponsored ?) IETF draft requesting the IPv6 /64
> and an IPv4 / 24 prefixes for similar use cases, way nicer and easier
> reference for similar future documents
>
>
>
> In all cases, I am afraid that an IETF Last Call & IESG evaluation should
> be done again as it is a not a minor editorial change.
>
>
>
> Early allocation could be requested for 2) and 3) within weeks.
>
>
>
> For 3) the MPLS/NVO3 documents could be quickly approved by the IESG with
> a normative reference to the short draft.
>
>
>
> Even if I mostly care about IPv6, I think that a solution for IPv4 is
> important. The solution 3) is much nicer albeit probably causing delays in *
> *publication** of the MPLS/NVO3 drafts but not for their **approvals**.
>
>
>
> On my side, 3) is the best way forward, but happy to listen to the
> community feedback
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Thursday, 9 January 2025 at 22:04
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail]
> <[e-mail]>, NVO3 <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>,
> Bocci, Matthew (Nokia - GB) <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08:
> (with DISCUSS and COMMENT)
>
> Merging two discussions might help us reach an acceptable solution.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jan 9, 2025 at 10:28 AM Greg Mirsky <[e-mail]> wrote:
>
> Hi Eric,
>
> thank you for the discussion and further clarification of your concern
> with the proposed use of ::1/128 as the inner destination IPv6 address in
> tunneled active OAM packets. Please see my follow-up notes below tagged
> GIM2>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Jan 9, 2025 at 5:35 AM Eric Vyncke (evyncke) <[e-mail]>
> wrote:
>
> Hello Greg,
>
>
>
> Thanks for your reply.
>
>
>
> A quick and easy point first: my comment on section 3.1 is really
> s\0:0:0:0:0:FFFF:7F00/104\::ffff:7f00/104\ or \::ffff:127.0.0.0/104\
> <http://127.0.0.0/104%5C> (and no need to add a reference to RFC 5952).
> Sorry if I was unclear in my comment.
>
> GIM2>> Thank you for the clarification. I used the first option, changing
> 'F' into 'f'.
>
>
>
> This leads of course to the core of my DISCUSS: using ::1 as the inner
> destination address to avoid the dummy inner packet to be consumed by a
> non-intended recipient. Like ::ff00:127.0.0.0/104 it is a violation of
> RFC 4291 even if slightly nicer.
>
>
>
> Did the MPLS WG consider the use of RFC 6666 (discard prefix) 100::/64 ?
> This would also have the benefit of allowing entry in the destination
> address to allow for ECMP testing.
>
> GIM2>> Thank you for pointing out this option. AFAIK when the first RFC,
> RFC 4379, was published defining IP/UDP encapsulation of active OAM packets
> in the MPLS network, the IPv6 range was not assigned yet. Also, RFC 9570
> <https://datatracker.ietf.org/doc/rfc9570/> recommends using ::1/128 as
> the inner destination IPv6 address in IP/UDP encapsulation of an active OAM
> packet in the MPLS network. I believe using an IPv6 address in IP/UDP
> encapsulation must be consistent across all cases, whether MPLS or IPv6
> tunneling.
>
>
>
> E.g., the following text would be better IMHO (keeping the 2nd bullet to
> support legacy implementations):
>
> “This document updates Section 5.8 of [RFC8562
> <https://www.rfc-editor.org/info/rfc8562>] regarding the selection of the
> IPv6 destination address:
>
> ·         The sender of an echo request SHOULD select the IPv6
> destination from the 100::/64 RFC 6666 prefix.
>
> ·         The sender of an echo request MAY select the IPv6 destination
> address from the 0:0:0:0:0:FFFF:7F00/104 prefix.”
>
> Alternatively, IANA could easily assign another /64 for the use of BFD.
>
> GIM2>> As this issue is present in both documents,
> draft-ietf-mpls-p2mp-bfd, and draft-ietf-nvo3-geneve-oam, I defer to ADs
> and WG Chairs for their suggestions and guidance.
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Greg Mirsky <[e-mail]>
> *Date: *Monday, 6 January 2025 at 20:49
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>, [e-mail]
> <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-mpls-p2mp-bfd-08:
> (with DISCUSS and COMMENT)
>
> Hi Éric,
>
> thank you for your review and comments. Please find my notes below tagged
> GIM>>. The attached diff highlights updates applied in the new working
> version.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Jan 6, 2025 at 4:13 AM Éric Vyncke via Datatracker <
> [e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-mpls-p2mp-bfd-08: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mpls-p2mp-bfd/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-mpls-p2mp-bfd-08
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points, some non-blocking COMMENT
> points
> (but replies would be appreciated even if only for my own education), and
> some
> nits.
>
> Special thanks to Nicolai Leymann for the shepherd's detailed write-up
> including the WG consensus *but it lacks* the justification of the intended
> status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## DISCUSS (blocking)
>
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is just a request to have a discussion on the following
> topics:
>
> ### Section 3.1
>
> Happy to stand corrected, but I read section 3.1 as IP packets are sent
> outside
> of a node on a real (p2mp) link with a destination address of ::1/128. If
> confirmed, then this is an apparent violation of section 2.5.3 of RFC 4291
> (even if sent over MPLS).
>
> GIM>> The use of a loopback IP address as the destination in
> MPLS-encapsulated IP/UDP was introduced in RFC 4379 (it was obsoleted by RFC
> 8029 <https://datatracker.ietf.org/doc/html/rfc8029>). In it, the use of
> a loopback discussed in Section 2.1. Use of a loopback IPv4 address as the
> destination address in MPLS-encapsulated IP/UDP active OAM, e.g., LSP Echo
> request/reply (RFC 8029) or BFD (RFC 5884), as I understand is accepted and
> broadly deployed. This document is intended to correct earlier
> misconception about IPv6-mapped IPv4 loopback address range and recommends
> using IPv6 loopback as the destination address in IP/UDP encapsulation over
> MPLS.
>
>
> I understand that this violation started already in RFC 8562, and I have no
> obvious solution to propose except using a link-local mcast address, e.g.,
> ff02::2/128 (all link routers).
>
> GIM>> The intention of using a loopback address as the IP destination
> address in IP/UDP encapsulation of an active OAM over MPLS discussed in Section
> 2.1 of RFC 8029
> <https://datatracker.ietf.org/doc/html/rfc8029#section-2.1>:
>
>    1.  Although the LSP in question may be broken in unknown ways, the
>
>        likelihood of a diagnostic packet being delivered to a user of an
>
>        MPLS service MUST be held to an absolute minimum.
>
>
>
>    2.  If an LSP is broken in such a way that it prematurely terminates,
>
>        the diagnostic packet MUST NOT be IP forwarded.
>
>
>
>    3.  A means of varying the diagnostic packets such that they exercise
>
>        all ECMP paths is thus REQUIRED.
>
> It seems like using link-local mcast address would not comply to these
> requirements, but a loopback address is complying.
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> ## COMMENTS (non-blocking)
>
> ### Abstract and Section 1
>
> s/recommends the use of *an* IPv6 loopback address/recommends the use of
> *the*
> IPv6 loopback address/
>
> GIM>> Thank you; done.
>
>
> ### Section 2.1
>
> Suggest adding a reference (or a definition) of `G-ACh`.
>
> GIM>> Added reference to RFC 5586 in Section 3.2 and expanded on the first
> use of the abbreviation.
>
>
> ### Section 3.1
>
> Please use section 5 of RFC 5952 for `0:0:0:0:0:FFFF:7F00/104`.
>
> GIMM>> Added as Informative reference. Would you agree?
>
>
> ### Section 3.2
>
> In figure 1, some fields have a length that is specified and others have no
> length... Is it on purpose ?
>
> GIM>> Thank you for pointing that out to me. I removed occurences of '(16
> bits)'.
>
>
> Even if the reader could guess, what are the expected sender/receiver
> behavior
> for the reserved fields ?
>
> GIM>> The Source Address TLV is defined in Section 4.1 of RFC 7212
> <https://www.rfc-editor.org/rfc/rfc7212.html>. Would you recommend
> clarificaton of how its fields are handled?
>
>
> ## NITS (non-blocking / cosmetic)
>
> ### Use of SVG graphics
>
> To make a much nicer HTML rendering, suggest using the aasvg too to
> generate
> SVG graphics. It is worth a try ;-)
>
> GIM>> I will try it ;)
>
>