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

[Greg Mirsky <[e-mail]>]

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 ;)
>
>