[nvo3] Re: Éric Vyncke's Discuss on draft-ietf-mpls-p 2mp-bfd-08: (with DISCUSS and COMMENT)
Greg Mirsky <[email protected]> Tue, 4 Feb 2025 19:42:28 -0800
| Newsgroups | gmane.ietf.nvo3,gmane.ietf.mpls |
|---|---|
| Message-ID | <CA+RyBmXcm=qCvxMaEVU-Ph7LSA8r9ELKBSn7biTquZum9uBxsQ@mail.gmail.com> |
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) <[email protected]>
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 <[email protected]>
> *Date: *Tuesday, 14 January 2025 at 17:01
> *To: *Gunter van de Velde (Nokia) <[email protected]>
> *Cc: *Eric Vyncke (evyncke) <[email protected]>, The IESG <[email protected]>,
> [email protected] <[email protected]>,
> [email protected] <[email protected]>, NVO3 <[email protected]>, [email protected]
> <[email protected]>, [email protected] <
> [email protected]>
> *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) <
> [email protected]> 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=40cisco.com-Tr9gZwTxerDR74oF6e/[email protected]>
> *Sent:* Tuesday, January 14, 2025 2:50 PM
> *To:* Greg Mirsky <[email protected]>; The IESG <[email protected]>
> *Cc:* [email protected]; [email protected]; NVO3 <
> [email protected]>; [email protected]; [email protected]
> *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 <[email protected]>
> *Date: *Friday, 10 January 2025 at 23:14
> *To: *Eric Vyncke (evyncke) <[email protected]>
> *Cc: *The IESG <[email protected]>, [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, [email protected] <[email protected]>, [email protected]
> <[email protected]>, NVO3 <[email protected]>, [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, Bocci, Matthew (Nokia - GB) <
> [email protected]>
> *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) <[email protected]>
> 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 <[email protected]>
> *Date: *Thursday, 9 January 2025 at 22:04
> *To: *Eric Vyncke (evyncke) <[email protected]>
> *Cc: *The IESG <[email protected]>, [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, [email protected] <[email protected]>, [email protected]
> <[email protected]>, NVO3 <[email protected]>, [email protected] <
> [email protected]>, [email protected] <[email protected]>,
> [email protected] <[email protected]>,
> Bocci, Matthew (Nokia - GB) <[email protected]>
> *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 <[email protected]> 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) <[email protected]>
> 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 <[email protected]>
> *Date: *Monday, 6 January 2025 at 20:49
> *To: *Eric Vyncke (evyncke) <[email protected]>
> *Cc: *The IESG <[email protected]>, [email protected] <
> [email protected]>, [email protected] <
> [email protected]>, [email protected] <[email protected]>, [email protected]
> <[email protected]>
> *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 <
> [email protected]> 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 ;)
>
>
_______________________________________________
nvo3 mailing list -- [email protected]
To unsubscribe send an email to [email protected]
draft-ietf-nvo3-geneve-oam-15.diff.html
(text/html, 58 KB)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Generated by rfcdiff 1.49: rfcdiff -->
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional" > -->
<!-- System: Linux at-author-tools-cc675b9d6-4t8gm 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 x86_64 x86_64 GNU/Linux -->
<!-- Using awk: /usr/bin/gawk: GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0) -->
<!-- Using diff: /usr/bin/diff: diff (GNU diffutils) 3.10 -->
<!-- Using wdiff: /usr/bin/wdiff: wdiff (GNU wdiff) 1.2.2 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<title>Diff: draft-ietf-nvo3-geneve-oam-14.txt - draft-ietf-nvo3-geneve-oam-15.txt</title>
<style type="text/css">
body { margin: 0.4ex; margin-right: auto; }
tr { }
td { white-space: pre; font-family: monospace; vertical-align: top; font-size: 0.86em;}
th { font-size: 0.86em; }
.small { font-size: 0.6em; font-style: italic; font-family: Verdana, Helvetica, sans-serif; }
.left { background-color: #EEE; }
.right { background-color: #FFF; }
.diff { background-color: #CCF; }
.lblock { background-color: #BFB; }
.rblock { background-color: #FF8; }
.insert { background-color: #8FF; }
.delete { background-color: #ACF; }
.void { background-color: #FFB; }
.cont { background-color: #EEE; }
.linebr { background-color: #AAA; }
.lineno { color: red; background-color: #FFF; font-size: 0.7em; text-align: right; padding: 0 2px; }
.elipsis{ background-color: #AAA; }
.left .cont { background-color: #DDD; }
.right .cont { background-color: #EEE; }
.lblock .cont { background-color: #9D9; }
.rblock .cont { background-color: #DD6; }
.insert .cont { background-color: #0DD; }
.delete .cont { background-color: #8AD; }
.stats, .stats td, .stats th { background-color: #EEE; padding: 2px 0; }
span.hide { display: none; color: #aaa;} a:hover span { display: inline; } tr.change { background-color: gray; }
tr.change a { text-decoration: none; color: black }
</style>
<script>
var chunk_index = 0;
var old_chunk = null;
function format_chunk(index) {
var prefix = "diff";
var str = index.toString();
for (x=0; x<(4-str.length); ++x) {
prefix+='0';
}
return prefix + str;
}
function find_chunk(n){
return document.querySelector('tr[id$="' + n + '"]');
}
function change_chunk(offset) {
var index = chunk_index + offset;
var new_str;
var new_chunk;
new_str = format_chunk(index);
new_chunk = find_chunk(new_str);
if (!new_chunk) {
return;
}
if (old_chunk) {
old_chunk.style.outline = "";
}
old_chunk = new_chunk;
old_chunk.style.outline = "1px solid red";
window.location.hash = "#" + new_str;
window.scrollBy(0,-100);
chunk_index = index;
}
document.onkeydown = function(e) {
switch (e.keyCode) {
case 78:
change_chunk(1);
break;
case 80:
change_chunk(-1);
break;
}
};
</script>
</head>
<body >
<table border="0" cellpadding="0" cellspacing="0">
<tr id="part-1" bgcolor="orange"><th></th><th> draft-ietf-nvo3-geneve-oam-14.txt </th><th> </th><th> draft-ietf-nvo3-geneve-oam-15.txt </th><th></th></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">NVO3 Working Group G. Mirsky</td><td> </td><td class="right">NVO3 Working Group G. Mirsky</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Internet-Draft Ericsson</td><td> </td><td class="right">Internet-Draft Ericsson</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Intended status: Standards Track S. Boutros</td><td> </td><td class="right">Intended status: Standards Track S. Boutros</td><td class="lineno"></td></tr>
<tr id="diff0001"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock">Expires: <span class="delete">7 July 2025 </span> Ciena</td><td> </td><td class="rblock">Expires: <span class="insert">9 August 2025</span> Ciena</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> D. Black</td><td> </td><td class="right"> D. Black</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Dell EMC</td><td> </td><td class="right"> Dell EMC</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> S. Pallagatti</td><td> </td><td class="right"> S. Pallagatti</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> VMware</td><td> </td><td class="right"> VMware</td><td class="lineno"></td></tr>
<tr id="diff0002"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete"> 3 Jan</span>uary 2025</td><td> </td><td class="rblock"> <span class="insert">5 Febr</span>uary 2025</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0003"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Active OAM for use in <span class="delete">GENEVE</span></td><td> </td><td class="rblock"> Active OAM for use in <span class="insert">Geneve</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> draft-ietf-nvo3-geneve-oam-14</span></td><td> </td><td class="rblock"><span class="insert"> draft-ietf-nvo3-geneve-oam-15</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Abstract</td><td> </td><td class="right">Abstract</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Geneve (Generic Network Virtualization Encapsulation) is a flexible</td><td> </td><td class="right"> Geneve (Generic Network Virtualization Encapsulation) is a flexible</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and extensible network virtualization overlay protocol designed to</td><td> </td><td class="right"> and extensible network virtualization overlay protocol designed to</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> encapsulate network packets for transport across underlying physical</td><td> </td><td class="right"> encapsulate network packets for transport across underlying physical</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> networks. This document specifies the requirements and provides a</td><td> </td><td class="right"> networks. This document specifies the requirements and provides a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> framework for Operations, Administration, and Maintenance (OAM) in</td><td> </td><td class="right"> framework for Operations, Administration, and Maintenance (OAM) in</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Geneve networks. It outlines the OAM functions necessary to monitor,</td><td> </td><td class="right"> Geneve networks. It outlines the OAM functions necessary to monitor,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> diagnose, and troubleshoot Geneve overlay networks to ensure proper</td><td> </td><td class="right"> diagnose, and troubleshoot Geneve overlay networks to ensure proper</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-2" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-2"><em> page 1, line 45<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-2"><em> page 1, line 45<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> Internet-Drafts are working documents of the Internet Engineering</td><td> </td><td class="right"> Internet-Drafts are working documents of the Internet Engineering</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Task Force (IETF). Note that other groups may also distribute</td><td> </td><td class="right"> Task Force (IETF). Note that other groups may also distribute</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> working documents as Internet-Drafts. The list of current Internet-</td><td> </td><td class="right"> working documents as Internet-Drafts. The list of current Internet-</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td> </td><td class="right"> Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Internet-Drafts are draft documents valid for a maximum of six months</td><td> </td><td class="right"> Internet-Drafts are draft documents valid for a maximum of six months</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and may be updated, replaced, or obsoleted by other documents at any</td><td> </td><td class="right"> and may be updated, replaced, or obsoleted by other documents at any</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> time. It is inappropriate to use Internet-Drafts as reference</td><td> </td><td class="right"> time. It is inappropriate to use Internet-Drafts as reference</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> material or to cite them other than as "work in progress."</td><td> </td><td class="right"> material or to cite them other than as "work in progress."</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0004"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> This Internet-Draft will expire on <span class="delete">7 July</span> 2025.</td><td> </td><td class="rblock"> This Internet-Draft will expire on <span class="insert">9 August</span> 2025.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Copyright Notice</td><td> </td><td class="right">Copyright Notice</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Copyright (c) 2025 IETF Trust and the persons identified as the</td><td> </td><td class="right"> Copyright (c) 2025 IETF Trust and the persons identified as the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> document authors. All rights reserved.</td><td> </td><td class="right"> document authors. All rights reserved.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This document is subject to BCP 78 and the IETF Trust's Legal</td><td> </td><td class="right"> This document is subject to BCP 78 and the IETF Trust's Legal</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td> </td><td class="right"> Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> license-info) in effect on the date of publication of this document.</td><td> </td><td class="right"> license-info) in effect on the date of publication of this document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Please review these documents carefully, as they describe your rights</td><td> </td><td class="right"> Please review these documents carefully, as they describe your rights</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and restrictions with respect to this document. Code Components</td><td> </td><td class="right"> and restrictions with respect to this document. Code Components</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> extracted from this document must include Revised BSD License text as</td><td> </td><td class="right"> extracted from this document must include Revised BSD License text as</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> described in Section 4.e of the Trust Legal Provisions and are</td><td> </td><td class="right"> described in Section 4.e of the Trust Legal Provisions and are</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> provided without warranty as described in the Revised BSD License.</td><td> </td><td class="right"> provided without warranty as described in the Revised BSD License.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Table of Contents</td><td> </td><td class="right">Table of Contents</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2</td><td> </td><td class="right"> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 1.1. Conventions used in this document . . . . . . . . . . . . 3</td><td> </td><td class="right"> 1.1. Conventions used in this document . . . . . . . . . . . . 3</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3</td><td> </td><td class="right"> 1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3</td><td class="lineno"></td></tr>
<tr id="diff0005"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 1.1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . <span class="delete">3</span></td><td> </td><td class="rblock"> 1.1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . <span class="insert">4</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2. The Applicability of Active OAM Protocols in Geneve</td><td> </td><td class="right"> 2. The Applicability of Active OAM Protocols in Geneve</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Networks . . . . . . . . . . . . . . . . . . . . . . . . 4</td><td> </td><td class="right"> Networks . . . . . . . . . . . . . . . . . . . . . . . . 4</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2.1. Requirements for Active OAM Protocols in Geneve</td><td> </td><td class="right"> 2.1. Requirements for Active OAM Protocols in Geneve</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Networks . . . . . . . . . . . . . . . . . . . . . . . . 4</td><td> </td><td class="right"> Networks . . . . . . . . . . . . . . . . . . . . . . . . 4</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2.2. Defect Detection and Troubleshooting in Geneve Network with</td><td> </td><td class="right"> 2.2. Defect Detection and Troubleshooting in Geneve Network with</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Active OAM . . . . . . . . . . . . . . . . . . . . . . . 5</td><td> </td><td class="right"> Active OAM . . . . . . . . . . . . . . . . . . . . . . . 5</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2.2.1. Echo Request and Echo Reply in Geneve Tunnel . . . . 7</td><td> </td><td class="right"> 2.2.1. Echo Request and Echo Reply in Geneve Tunnel . . . . 7</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2.3. Active OAM Encapsulation in Geneve . . . . . . . . . . . 8</td><td> </td><td class="right"> 2.3. Active OAM Encapsulation in Geneve . . . . . . . . . . . 8</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 6.1. Normative References . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 6.1. Normative References . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr id="diff0006"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 6.2. Informative References . . . . . . . . . . . . . . . . . <span class="delete"> 9</span></td><td> </td><td class="rblock"> 6.2. Informative References . . . . . . . . . . . . . . . . . <span class="insert">10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11</td><td> </td><td class="right"> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">1. Introduction</td><td> </td><td class="right">1. Introduction</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Geneve [RFC8926] is designed to support various scenarios of network</td><td> </td><td class="right"> Geneve [RFC8926] is designed to support various scenarios of network</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> virtualization. It encapsulates multiple protocols, such as Ethernet</td><td> </td><td class="right"> virtualization. It encapsulates multiple protocols, such as Ethernet</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and IPv4/IPv6, and includes metadata within the Geneve message.</td><td> </td><td class="right"> and IPv4/IPv6, and includes metadata within the Geneve message.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Operations, Administration, and Maintenance (OAM) protocols provide</td><td> </td><td class="right"> Operations, Administration, and Maintenance (OAM) protocols provide</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> fault management and performance monitoring functions necessary for</td><td> </td><td class="right"> fault management and performance monitoring functions necessary for</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-3" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-3"><em> page 3, line 24<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-3"><em> page 3, line 24<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> receives the same Quality of Service treatment as the monitored</td><td> </td><td class="right"> receives the same Quality of Service treatment as the monitored</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> object. In this context, the monitored object refers to either</td><td> </td><td class="right"> object. In this context, the monitored object refers to either</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> the Geneve tunnel as a whole or a specific tenant flow within a</td><td> </td><td class="right"> the Geneve tunnel as a whole or a specific tenant flow within a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> given Geneve tunnel.</td><td> </td><td class="right"> given Geneve tunnel.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Section 2.1 of this document lists the general requirements for</td><td> </td><td class="right"> Section 2.1 of this document lists the general requirements for</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> active OAM protocols in the Geneve overlay network. IP encapsulation</td><td> </td><td class="right"> active OAM protocols in the Geneve overlay network. IP encapsulation</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> meets these requirements and is suitable for encapsulating active OAM</td><td> </td><td class="right"> meets these requirements and is suitable for encapsulating active OAM</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> protocols within a Geneve overlay network. Active OAM messages in a</td><td> </td><td class="right"> protocols within a Geneve overlay network. Active OAM messages in a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Geneve overlay network are exchanged between two Geneve tunnel</td><td> </td><td class="right"> Geneve overlay network are exchanged between two Geneve tunnel</td><td class="lineno"></td></tr>
<tr id="diff0007"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> endpoints, which may be <span class="delete">a</span> Network Virtualization Edge (NVE) or</td><td> </td><td class="rblock"> endpoints, which may be <span class="insert">the tenant-facing interface of the</span> Network</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> another device acting as a Geneve tunnel endpoint. For simplicity,</td><td> </td><td class="rblock"> Virtualization Edge (NVE) or another device acting as a Geneve tunnel</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> this document uses an NVE to represent the Geneve tunnel endpoint.</td><td> </td><td class="rblock"> endpoint. <span class="insert">Testing end-to-end between tenants is out of scope.</span> For</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Refer to [RFC7365] and [RFC8014] for detailed definitions and</td><td> </td><td class="rblock"> simplicity, this document uses an NVE to represent the Geneve tunnel</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> descriptions of an NVE.</td><td> </td><td class="rblock"> endpoint. Refer to [RFC7365] and [RFC8014] for detailed definitions</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> and descriptions of an NVE.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The IP encapsulation of Geneve OAM defined in this document applies</td><td> </td><td class="right"> The IP encapsulation of Geneve OAM defined in this document applies</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> to an overlay service by introducing a Management Virtual Network</td><td> </td><td class="right"> to an overlay service by introducing a Management Virtual Network</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Identifier (VNI), which can be used in combination with various</td><td> </td><td class="right"> Identifier (VNI), which can be used in combination with various</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> values of the Protocol Type field in the Geneve header, such as</td><td> </td><td class="right"> values of the Protocol Type field in the Geneve header, such as</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Ethertypes for IPv4 or IPv6. The analysis and definition of other</td><td> </td><td class="right"> Ethertypes for IPv4 or IPv6. The analysis and definition of other</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> types of OAM encapsulation in Geneve are outside the scope of this</td><td> </td><td class="right"> types of OAM encapsulation in Geneve are outside the scope of this</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> document.</td><td> </td><td class="right"> document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">1.1. Conventions used in this document</td><td> </td><td class="right">1.1. Conventions used in this document</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-4" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-4"><em> page 7, line 14<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-4"><em> page 7, line 14<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> dedicated to carrying only control and management data between the</td><td> </td><td class="right"> dedicated to carrying only control and management data between the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> tunnel endpoints, hence it is referred to as a Geneve control channel</td><td> </td><td class="right"> tunnel endpoints, hence it is referred to as a Geneve control channel</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and that VNI is referred to as the Management VNI. A configured VNI</td><td> </td><td class="right"> and that VNI is referred to as the Management VNI. A configured VNI</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MAY be used to identify the control channel, but it is RECOMMENDED</td><td> </td><td class="right"> MAY be used to identify the control channel, but it is RECOMMENDED</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> that the default value 1 be used as the Management VNI.</td><td> </td><td class="right"> that the default value 1 be used as the Management VNI.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Encapsulation of test packets using the Management VNI is discussed</td><td> </td><td class="right"> Encapsulation of test packets using the Management VNI is discussed</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> in Section 2.3.</td><td> </td><td class="right"> in Section 2.3.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The control channel of a Geneve tunnel MUST NOT carry tenant data.</td><td> </td><td class="right"> The control channel of a Geneve tunnel MUST NOT carry tenant data.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> As no tenants are connected using the control channel, a system that</td><td> </td><td class="right"> As no tenants are connected using the control channel, a system that</td><td class="lineno"></td></tr>
<tr id="diff0008"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> supports this <span class="delete">specification,</span> MUST NOT forward a packet received over</td><td> </td><td class="rblock"> supports this <span class="insert">specification</span> MUST NOT forward a packet received over</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> the control channel to any tenant. A packet received over the</td><td> </td><td class="rblock"> the control channel to any tenant. A packet received <span class="insert">by the system</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> control channel MUST be forwarded if and only if it is sent onto the</td><td> </td><td class="rblock"><span class="insert"> that supports this specification</span> over the control channel MUST be</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> control channel of the concatenated Geneve tunnel. Else, it MUST be</td><td> </td><td class="rblock"> forwarded if and only if it is sent onto the control channel of the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> terminated locally. The Management VNI SHOULD be terminated on the</td><td> </td><td class="rblock"> concatenated Geneve tunnel. Else, it MUST be terminated locally.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> tenant-facing side of the Geneve encapsulation/decapsulation</td><td> </td><td class="rblock"> The Management VNI SHOULD be terminated on the tenant-facing side of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> functionality, not the <span class="delete">DC-network-facing</span> side (per definitions in</td><td> </td><td class="rblock"> the Geneve encapsulation/decapsulation functionality, not the <span class="insert">DC-</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Section 4 of [RFC8014]) so that Geneve encap/decap functionality is</td><td> </td><td class="rblock"><span class="insert"> network-facing</span> side (per definitions in Section 4 of [RFC8014]) so</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> included in its scope. This approach causes an active OAM packet,</td><td> </td><td class="rblock"> that Geneve encap/decap functionality is included in its scope. This</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> e.g., an ICMP echo request, to be decapsulated in the same fashion as</td><td> </td><td class="rblock"> approach causes an active OAM packet, e.g., an ICMP echo request, to</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> any other received Geneve packet. In this example, the resulting</td><td> </td><td class="rblock"> be decapsulated in the same fashion as any other received Geneve</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> ICMP packet is handed to NVE's local management functionality for the</td><td> </td><td class="rblock"> packet. In this example, the resulting ICMP packet is handed to</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> processing which generates an ICMP echo reply. The ICMP echo reply</td><td> </td><td class="rblock"> NVE's local management functionality for the processing which</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> is encapsulated in Geneve as specified in Section 2.3. for forwarding</td><td> </td><td class="rblock"> generates an ICMP echo reply. The ICMP echo reply is encapsulated in</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> back to the NVE that sent the echo request. One advantage of this</td><td> </td><td class="rblock"> Geneve as specified in Section 2.3. for forwarding back to the NVE</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> approach is that a repeated ICMP echo request/reply test could detect</td><td> </td><td class="rblock"> that sent the echo request. One advantage of this approach is that a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> an intermittent problem in Geneve encap/decap hardware, which would</td><td> </td><td class="rblock"> repeated ICMP echo request/reply test could detect an intermittent</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> not be tested if the Management VNI were handled as a "special case"</td><td> </td><td class="rblock"> problem in Geneve encap/decap hardware, which would not be tested if</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> at the <span class="delete">DC-network-facing</span> interface.</td><td> </td><td class="rblock"> the Management VNI were handled as a "special case" at the <span class="insert">DC-</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> network-facing</span> interface.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The second case is when a test packet is transmitted using the VNI</td><td> </td><td class="right"> The second case is when a test packet is transmitted using the VNI</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> value associated with the monitored service flow. By doing that, the</td><td> </td><td class="right"> value associated with the monitored service flow. By doing that, the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> test packet experiences network treatment as the tenant's packets.</td><td> </td><td class="right"> test packet experiences network treatment as the tenant's packets.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> An example of the realization of that scenario is discussed in</td><td> </td><td class="right"> An example of the realization of that scenario is discussed in</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC9521].</td><td> </td><td class="right"> [RFC9521].</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">2.2.1. Echo Request and Echo Reply in Geneve Tunnel</td><td> </td><td class="right">2.2.1. Echo Request and Echo Reply in Geneve Tunnel</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively), as noted</td><td> </td><td class="right"> ICMP and ICMPv6 ([RFC0792] and [RFC4443] respectively), as noted</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-5" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-5"><em> page 9, line 4<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-5"><em> page 9, line 4<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> ~ Active OAM Packet ~</td><td> </td><td class="right"> ~ Active OAM Packet ~</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | |</td><td> </td><td class="right"> | |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active</td><td> </td><td class="right"> Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> OAM Packet</td><td> </td><td class="right"> OAM Packet</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Inner IP header:</td><td> </td><td class="right"> Inner IP header:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Destination IP: The IP address MUST be set to the loopback address</td><td> </td><td class="right"> Destination IP: The IP address MUST be set to the loopback address</td><td class="lineno"></td></tr>
<tr id="diff0009"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 127.0.0.1/32 for <span class="delete">IPv4, or</span> the <span class="delete">loopback</span> address <span class="delete">::1/128</span> for IPv6</td><td> </td><td class="rblock"> 127.0.0.1/32 for <span class="insert">IPv4 version. For IPv6,</span> the address <span class="insert">MUST be</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete">[RFC4291].</span></td><td> </td><td class="rblock"><span class="insert"> selected from the Associated Channel IPv6 Range</span> for IPv6</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">[I-D.ietf-mpls-p2mp-bfd].</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Source IP: IP address of the NVE.</td><td> </td><td class="right"> Source IP: IP address of the NVE.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0010"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> TTL or Hop Limit: MUST be set to 255 per [RFC5082].</td><td> </td><td class="rblock"> TTL or Hop Limit: MUST be set to 255 per [RFC5082]. <span class="insert">The receiver</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> of an active OAM Geneve packet with IP/UDP encapsulation MUST drop</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> packets whose TTL/Hop Limit is not 255.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">3. IANA Considerations</td><td> </td><td class="right">3. IANA Considerations</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This document has no requirements for IANA. This section can be</td><td> </td><td class="right"> This document has no requirements for IANA. This section can be</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> removed before the publication.</td><td> </td><td class="right"> removed before the publication.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">4. Security Considerations</td><td> </td><td class="right">4. Security Considerations</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> As part of a Geneve network, active OAM inherits the security</td><td> </td><td class="right"> As part of a Geneve network, active OAM inherits the security</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> considerations discussed in [RFC8926]. Additionally, a system MUST</td><td> </td><td class="right"> considerations discussed in [RFC8926]. Additionally, a system MUST</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> provide control to limit the rate of Geneve OAM packets punted to the</td><td> </td><td class="right"> provide control to limit the rate of Geneve OAM packets punted to the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Geneve control plane for processing in order to avoid overloading</td><td> </td><td class="right"> Geneve control plane for processing in order to avoid overloading</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> that control plane.</td><td> </td><td class="right"> that control plane.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0011"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> OAM in G<span class="delete">ENEVE</span> packets uses the General TTL Security Mechanism</td><td> </td><td class="rblock"> OAM in G<span class="insert">eneve</span> packets uses the General TTL Security Mechanism</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC5082], and any packet received with an inner TTL / Hop Count</td><td> </td><td class="right"> [RFC5082], and any packet received with an inner TTL / Hop Count</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> other than 255 MUST be discarded.</td><td> </td><td class="right"> other than 255 MUST be discarded.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">5. Acknowledgments</td><td> </td><td class="right">5. Acknowledgments</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The authors express their appreciation to Donald E. Eastlake 3rd for</td><td> </td><td class="right"> The authors express their appreciation to Donald E. Eastlake 3rd for</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> his suggestions that improved the readability of the document.</td><td> </td><td class="right"> his suggestions that improved the readability of the document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">6. References</td><td> </td><td class="right">6. References</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">6.1. Normative References</td><td> </td><td class="right">6.1. Normative References</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0012"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">[I-D.ietf-mpls-p2mp-bfd]</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Mirsky, G., Mishra, G. S., and D. E. Eastlake,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> "Bidirectional Forwarding Detection (BFD) for Multipoint</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Networks over Point-to-Multi-Point MPLS Label Switched</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Path (LSP)", Work in Progress, Internet-Draft, draft-ietf-</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> mpls-p2mp-bfd-09, 6 January 2025,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> p2mp-bfd-09>.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate</td><td> </td><td class="right"> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Requirement Levels", BCP 14, RFC 2119,</td><td> </td><td class="right"> Requirement Levels", BCP 14, RFC 2119,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> DOI 10.17487/RFC2119, March 1997,</td><td> </td><td class="right"> DOI 10.17487/RFC2119, March 1997,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc2119>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc2119>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC</td><td> </td><td class="right"> [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,</td><td> </td><td class="right"> 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> May 2017, <https://www.rfc-editor.org/info/rfc8174>.</td><td> </td><td class="right"> May 2017, <https://www.rfc-editor.org/info/rfc8174>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,</td><td> </td><td class="right"> [RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> "Geneve: Generic Network Virtualization Encapsulation",</td><td> </td><td class="right"> "Geneve: Generic Network Virtualization Encapsulation",</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> RFC 8926, DOI 10.17487/RFC8926, November 2020,</td><td> </td><td class="right"> RFC 8926, DOI 10.17487/RFC8926, November 2020,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc8926>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc8926>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">6.2. Informative References</td><td> </td><td class="right">6.2. Informative References</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,</td><td> </td><td class="right"> [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> RFC 792, DOI 10.17487/RFC0792, September 1981,</td><td> </td><td class="right"> RFC 792, DOI 10.17487/RFC0792, September 1981,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc792>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc792>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0013"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete">[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> Architecture", RFC 4291, DOI 10.17487/RFC4291, February</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> 2006, <https://www.rfc-editor.org/info/rfc4291>.</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> </td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet</td><td> </td><td class="right"> [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Control Message Protocol (ICMPv6) for the Internet</td><td> </td><td class="right"> Control Message Protocol (ICMPv6) for the Internet</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Protocol Version 6 (IPv6) Specification", STD 89,</td><td> </td><td class="right"> Protocol Version 6 (IPv6) Specification", STD 89,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> RFC 4443, DOI 10.17487/RFC4443, March 2006,</td><td> </td><td class="right"> RFC 4443, DOI 10.17487/RFC4443, March 2006,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc4443>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc4443>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,</td><td> </td><td class="right"> [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> "Extended ICMP to Support Multi-Part Messages", RFC 4884,</td><td> </td><td class="right"> "Extended ICMP to Support Multi-Part Messages", RFC 4884,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> DOI 10.17487/RFC4884, April 2007,</td><td> </td><td class="right"> DOI 10.17487/RFC4884, April 2007,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc4884>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc4884>.</td><td class="lineno"></td></tr>
<tr><td></td><td class="left"></td><td> </td><td class="right"></td><td></td></tr>
<tr id="end" bgcolor="gray"><th colspan="5" align="center"> End of changes. 13 change blocks. </th></tr>
<tr class="stats"><td></td><th><i>39 lines changed or deleted</i></th><th><i> </i></th><th><i>49 lines changed or added</i></th><td></td></tr>
<tr><td colspan="5" align="center" class="small"><br/>This html diff was produced by rfcdiff 1.49. The latest version is available from <a href="https://github.com/ietf-tools/rfcdiff" >https://github.com/ietf-tools/rfcdiff</a> </td></tr>
</table>
<script>(function(){function c(){var b=a.contentDocument||a.contentWindow.document;if(b){var d=b.createElement('script');d.innerHTML="window.__CF$cv$params={r:'90cfde220e18d7ab',t:'MTczODcyNjcwOC4wMDAwMDA='};var a=document.createElement('script');a.nonce='';a.src='/cdn-cgi/challenge-platform/scripts/jsd/main.js';document.getElementsByTagName('head')[0].appendChild(a);";b.getElementsByTagName('head')[0].appendChild(d)}}if(document.body){var a=document.createElement('iframe');a.height=1;a.width=1;a.style.position='absolute';a.style.top=0;a.style.left=0;a.style.border='none';a.style.visibility='hidden';document.body.appendChild(a);if('loading'!==document.readyState)c();else if(window.addEventListener)document.addEventListener('DOMContentLoaded',c);else{var e=document.onreadystatechange||function(){};document.onreadystatechange=function(b){e(b);'loading'!==document.readyState&&(document.onreadystatechange=e,c())}}}})();</script></body>
</html>
draft-ietf-mpls-p2mp-bfd-10.diff.html
(text/html, 89.3 KB)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!-- Generated by rfcdiff 1.49: rfcdiff -->
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional" > -->
<!-- System: Linux at-author-tools-cc675b9d6-4t8gm 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 x86_64 x86_64 GNU/Linux -->
<!-- Using awk: /usr/bin/gawk: GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0) -->
<!-- Using diff: /usr/bin/diff: diff (GNU diffutils) 3.10 -->
<!-- Using wdiff: /usr/bin/wdiff: wdiff (GNU wdiff) 1.2.2 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<title>Diff: draft-ietf-mpls-p2mp-bfd-09.txt - draft-ietf-mpls-p2mp-bfd-10.txt</title>
<style type="text/css">
body { margin: 0.4ex; margin-right: auto; }
tr { }
td { white-space: pre; font-family: monospace; vertical-align: top; font-size: 0.86em;}
th { font-size: 0.86em; }
.small { font-size: 0.6em; font-style: italic; font-family: Verdana, Helvetica, sans-serif; }
.left { background-color: #EEE; }
.right { background-color: #FFF; }
.diff { background-color: #CCF; }
.lblock { background-color: #BFB; }
.rblock { background-color: #FF8; }
.insert { background-color: #8FF; }
.delete { background-color: #ACF; }
.void { background-color: #FFB; }
.cont { background-color: #EEE; }
.linebr { background-color: #AAA; }
.lineno { color: red; background-color: #FFF; font-size: 0.7em; text-align: right; padding: 0 2px; }
.elipsis{ background-color: #AAA; }
.left .cont { background-color: #DDD; }
.right .cont { background-color: #EEE; }
.lblock .cont { background-color: #9D9; }
.rblock .cont { background-color: #DD6; }
.insert .cont { background-color: #0DD; }
.delete .cont { background-color: #8AD; }
.stats, .stats td, .stats th { background-color: #EEE; padding: 2px 0; }
span.hide { display: none; color: #aaa;} a:hover span { display: inline; } tr.change { background-color: gray; }
tr.change a { text-decoration: none; color: black }
</style>
<script>
var chunk_index = 0;
var old_chunk = null;
function format_chunk(index) {
var prefix = "diff";
var str = index.toString();
for (x=0; x<(4-str.length); ++x) {
prefix+='0';
}
return prefix + str;
}
function find_chunk(n){
return document.querySelector('tr[id$="' + n + '"]');
}
function change_chunk(offset) {
var index = chunk_index + offset;
var new_str;
var new_chunk;
new_str = format_chunk(index);
new_chunk = find_chunk(new_str);
if (!new_chunk) {
return;
}
if (old_chunk) {
old_chunk.style.outline = "";
}
old_chunk = new_chunk;
old_chunk.style.outline = "1px solid red";
window.location.hash = "#" + new_str;
window.scrollBy(0,-100);
chunk_index = index;
}
document.onkeydown = function(e) {
switch (e.keyCode) {
case 78:
change_chunk(1);
break;
case 80:
change_chunk(-1);
break;
}
};
</script>
</head>
<body >
<table border="0" cellpadding="0" cellspacing="0">
<tr id="part-1" bgcolor="orange"><th></th><th> draft-ietf-mpls-p2mp-bfd-09.txt </th><th> </th><th> draft-ietf-mpls-p2mp-bfd-10.txt </th><th></th></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">MPLS Working Group G. Mirsky</td><td> </td><td class="right">MPLS Working Group G. Mirsky</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Internet-Draft Ericsson</td><td> </td><td class="right">Internet-Draft Ericsson</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Updates: 8562 (if approved) G. Mishra</td><td> </td><td class="right">Updates: 8562 (if approved) G. Mishra</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Intended status: Standards Track Verizon Inc.</td><td> </td><td class="right">Intended status: Standards Track Verizon Inc.</td><td class="lineno"></td></tr>
<tr id="diff0001"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock">Expires: <span class="delete">10 July 2025 </span> D. Eastlake</td><td> </td><td class="rblock">Expires: <span class="insert">9 August 2025</span> D. Eastlake</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Independent</td><td> </td><td class="right"> Independent</td><td class="lineno"></td></tr>
<tr id="diff0002"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete"> 6 Jan</span>uary 2025</td><td> </td><td class="rblock"> <span class="insert">5 Febr</span>uary 2025</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over</td><td> </td><td class="right"> Bidirectional Forwarding Detection (BFD) for Multipoint Networks over</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Point-to-Multi-Point MPLS Label Switched Path (LSP)</td><td> </td><td class="right"> Point-to-Multi-Point MPLS Label Switched Path (LSP)</td><td class="lineno"></td></tr>
<tr id="diff0003"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> draft-ietf-mpls-p2mp-bfd-<span class="delete">09</span></td><td> </td><td class="rblock"> draft-ietf-mpls-p2mp-bfd-<span class="insert">10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Abstract</td><td> </td><td class="right">Abstract</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This document describes procedures for using Bidirectional Forwarding</td><td> </td><td class="right"> This document describes procedures for using Bidirectional Forwarding</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Detection (BFD) for multipoint networks to detect data plane failures</td><td> </td><td class="right"> Detection (BFD) for multipoint networks to detect data plane failures</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> in Multiprotocol Label Switching (MPLS) point-to-multipoint Label</td><td> </td><td class="right"> in Multiprotocol Label Switching (MPLS) point-to-multipoint Label</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint</td><td> </td><td class="right"> Switched Paths (LSPs) and Segment Routing (SR) point-to-multipoint</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> policies with SR over MPLS data plane.</td><td> </td><td class="right"> policies with SR over MPLS data plane.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Furthermore, this document also updates RFC 8562 and recommends the</td><td> </td><td class="right"> Furthermore, this document also updates RFC 8562 and recommends the</td><td class="lineno"></td></tr>
<tr id="diff0004"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> use of an IPv6 <span class="delete">loopback address (::1/128)</span> and discourages the use of</td><td> </td><td class="rblock"> use of an IPv6 <span class="insert">from the Associated Channel IPv6 range TBA2/64</span> and</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> an IPv4 loopback address mapped to IPv6.</td><td> </td><td class="rblock"> discourages the use of an IPv4 loopback address mapped to IPv6.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> It also describes the applicability of LSP Ping, as in-band, and the</td><td> </td><td class="right"> It also describes the applicability of LSP Ping, as in-band, and the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> control plane, as out-band, solutions to bootstrap a BFD session.</td><td> </td><td class="right"> control plane, as out-band, solutions to bootstrap a BFD session.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> It also describes the behavior of the active tail for head</td><td> </td><td class="right"> It also describes the behavior of the active tail for head</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> notification.</td><td> </td><td class="right"> notification.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Status of This Memo</td><td> </td><td class="right">Status of This Memo</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This Internet-Draft is submitted in full conformance with the</td><td> </td><td class="right"> This Internet-Draft is submitted in full conformance with the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-2" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-2"><em> page 1, line 48<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-2"><em> page 1, line 48<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> Internet-Drafts are working documents of the Internet Engineering</td><td> </td><td class="right"> Internet-Drafts are working documents of the Internet Engineering</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Task Force (IETF). Note that other groups may also distribute</td><td> </td><td class="right"> Task Force (IETF). Note that other groups may also distribute</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> working documents as Internet-Drafts. The list of current Internet-</td><td> </td><td class="right"> working documents as Internet-Drafts. The list of current Internet-</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td> </td><td class="right"> Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Internet-Drafts are draft documents valid for a maximum of six months</td><td> </td><td class="right"> Internet-Drafts are draft documents valid for a maximum of six months</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> and may be updated, replaced, or obsoleted by other documents at any</td><td> </td><td class="right"> and may be updated, replaced, or obsoleted by other documents at any</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> time. It is inappropriate to use Internet-Drafts as reference</td><td> </td><td class="right"> time. It is inappropriate to use Internet-Drafts as reference</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> material or to cite them other than as "work in progress."</td><td> </td><td class="right"> material or to cite them other than as "work in progress."</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0005"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> This Internet-Draft will expire on <span class="delete">10 July</span> 2025.</td><td> </td><td class="rblock"> This Internet-Draft will expire on <span class="insert">9 August</span> 2025.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Copyright Notice</td><td> </td><td class="right">Copyright Notice</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Copyright (c) 2025 IETF Trust and the persons identified as the</td><td> </td><td class="right"> Copyright (c) 2025 IETF Trust and the persons identified as the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> document authors. All rights reserved.</td><td> </td><td class="right"> document authors. All rights reserved.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This document is subject to BCP 78 and the IETF Trust's Legal</td><td> </td><td class="right"> This document is subject to BCP 78 and the IETF Trust's Legal</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td> </td><td class="right"> Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> license-info) in effect on the date of publication of this document.</td><td> </td><td class="right"> license-info) in effect on the date of publication of this document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Please review these documents carefully, as they describe your rights</td><td> </td><td class="right"> Please review these documents carefully, as they describe your rights</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-3" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-3"><em> page 2, line 35<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-3"><em> page 2, line 35<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 4</td><td> </td><td class="right"> 3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 4</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4</td><td> </td><td class="right"> 3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 5</td><td> </td><td class="right"> 3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 5</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 6</td><td> </td><td class="right"> 4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 6</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 6</td><td> </td><td class="right"> 4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 6</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7</td><td> </td><td class="right"> 4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS</td><td> </td><td class="right"> 5. Operation of Multipoint BFD with Active Tail over P2MP MPLS</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7</td><td> </td><td class="right"> LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9</td><td> </td><td class="right"> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9</td><td class="lineno"></td></tr>
<tr id="diff0006"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <span class="delete">9</span></td><td> </td><td class="rblock"> <span class="insert">7.1. IPv6 Address Allocation . . . . . . . . . . . . . . . . . 10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . <span class="delete">9</span></td><td> </td><td class="rblock"><span class="insert"> 7.2. Multipoint BFD over MPLS LSP Associated Channel Type . . 10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 9.1. Normative References . . . . . . . . . . . . . . . . . . <span class="delete">9</span></td><td> </td><td class="rblock"> 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <span class="insert">10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> 9.2. Informative References . . . . . . . . . . . . . . . . . <span class="delete">11</span></td><td> </td><td class="rblock"> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . <span class="insert">10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <span class="delete">11</span></td><td> </td><td class="rblock"> 9.1. Normative References . . . . . . . . . . . . . . . . . . <span class="insert">10</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> 9.2. Informative References . . . . . . . . . . . . . . . . . <span class="insert">12</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <span class="insert">12</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">1. Introduction</td><td> </td><td class="right">1. Introduction</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8562] defines a method of using Bidirectional Detection (BFD)</td><td> </td><td class="right"> [RFC8562] defines a method of using Bidirectional Detection (BFD)</td><td class="lineno"></td></tr>
<tr id="diff0007"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> [RFC5880] to monitor and detect <span class="delete">unicast</span> failures between the sender</td><td> </td><td class="rblock"> [RFC5880] to monitor and detect failures between the sender (head)</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> (head) and one or more receivers (tails) in multipoint or multicast</td><td> </td><td class="rblock"> and one or more receivers (tails) in multipoint or multicast</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> networks.</td><td> </td><td class="right"> networks.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8562] added two BFD session types - MultipointHead and</td><td> </td><td class="right"> [RFC8562] added two BFD session types - MultipointHead and</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MultipointTail. Throughout this document, MultipointHead and</td><td> </td><td class="right"> MultipointTail. Throughout this document, MultipointHead and</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MultipointTail refer to the value to which the bfd.SessionType is set</td><td> </td><td class="right"> MultipointTail refer to the value to which the bfd.SessionType is set</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> on a BFD endpoint.</td><td> </td><td class="right"> on a BFD endpoint.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> This document describes procedures for using such modes of BFD</td><td> </td><td class="right"> This document describes procedures for using such modes of BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> protocol to detect data plane failures in Multiprotocol Label</td><td> </td><td class="right"> protocol to detect data plane failures in Multiprotocol Label</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths</td><td> </td><td class="right"> Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> (LSPs) and Segment Routing (SR) point-to-multipoint policies with SR</td><td> </td><td class="right"> (LSPs) and Segment Routing (SR) point-to-multipoint policies with SR</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> over MPLS (SR-MPLS) data plane</td><td> </td><td class="right"> over MPLS (SR-MPLS) data plane</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The document also describes the applicability of out-band solutions</td><td> </td><td class="right"> The document also describes the applicability of out-band solutions</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> to bootstrap a BFD session in this environment.</td><td> </td><td class="right"> to bootstrap a BFD session in this environment.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Historically, an IPv6-mapped IPv4 loopback range</td><td> </td><td class="right"> Historically, an IPv6-mapped IPv4 loopback range</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> address::ffff:127.0.0.1/128 was mandated, although functionally, an</td><td> </td><td class="right"> address::ffff:127.0.0.1/128 was mandated, although functionally, an</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> IPv6 address from that range is not analogous to its IPv4</td><td> </td><td class="right"> IPv6 address from that range is not analogous to its IPv4</td><td class="lineno"></td></tr>
<tr id="diff0008"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> counterpart. This draft starts the transition to using the <span class="delete">proper</span></td><td> </td><td class="rblock"> counterpart. <span class="insert">Furthermore, using the loopback address as the</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> IPv6 <span class="delete">loopback address</span> as the IPv6 destination address in the IP/UDP</td><td> </td><td class="rblock"><span class="insert"> destination address, even for an inner IP encapsulation of a tunneled</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> encapsulation of active OAM over the MPLS data plane. Thus, this</td><td> </td><td class="rblock"><span class="insert"> packet violates Section 2.5.3 of [RFC4291]. Hence, IANA is requested</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> document also updates [RFC8562] and recommends the use of an IPv6</td><td> </td><td class="rblock"><span class="insert"> to allocate TBA2/64 range as a new Associated Channel IPv6 Prefix</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete">loopback</span> address <span class="delete">(::1/128)</span> while acknowledging that an address from</td><td> </td><td class="rblock"><span class="insert"> range that can be used for selecting destination IPv6 addresses for</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> IP/UDP encapsulation of management, control, and OAM packets.</span> This</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> draft starts the transition to using the IPv6 <span class="insert">addresses from the</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Associated Channel IPv6 Prefix range</span> as the IPv6 destination address</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> in the IP/UDP encapsulation of active OAM over the MPLS data plane.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> Thus, this document also updates [RFC8562] and recommends the use of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> an IPv6 address <span class="insert">from the Associated Channel IPv6 Prefix range TBA2/64</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> (Section 7.1)</span> while acknowledging that an address from</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> ::ffff:127.0.0.1/128 range might be used by existing implementations,</td><td> </td><td class="right"> ::ffff:127.0.0.1/128 range might be used by existing implementations,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> discourages the use of the IPv6-mapped IPv4 loopback range address.</td><td> </td><td class="right"> discourages the use of the IPv6-mapped IPv4 loopback range address.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> It also describes the behavior of the active tail for head</td><td> </td><td class="right"> It also describes the behavior of the active tail for head</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> notification.</td><td> </td><td class="right"> notification.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">2. Conventions used in this document</td><td> </td><td class="right">2. Conventions used in this document</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">2.1. Terminology</td><td> </td><td class="right">2.1. Terminology</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> ACH: Associated Channel Header</td><td> </td><td class="right"> ACH: Associated Channel Header</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> BFD: Bidirectional Forwarding Detection</td><td> </td><td class="right"> BFD: Bidirectional Forwarding Detection</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0009"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> GAL G-ACh Label</td><td> </td><td class="rblock"> GAL<span class="insert">:</span> G-ACh Label</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> G-ACh: Generic Associated Channel</td><td> </td><td class="right"> G-ACh: Generic Associated Channel</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSP: Label Switched Path</td><td> </td><td class="right"> LSP: Label Switched Path</td><td class="lineno"></td></tr>
<tr id="diff0010"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> </span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSR: Label Switching Router</td><td> </td><td class="right"> LSR: Label Switching Router</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MPLS: Multiprotocol Label Switching</td><td> </td><td class="right"> MPLS: Multiprotocol Label Switching</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> p2mp: Point-to-Multipoint</td><td> </td><td class="right"> p2mp: Point-to-Multipoint</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> SR: Segment Routing</td><td> </td><td class="right"> SR: Segment Routing</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> SR-MPLS: SR over MPLS</td><td> </td><td class="right"> SR-MPLS: SR over MPLS</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-4" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-4"><em> page 4, line 35<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-4"><em> page 4, line 44<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> the source IP address MUST be used to demultiplex the received BFD</td><td> </td><td class="right"> the source IP address MUST be used to demultiplex the received BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Control packet as described in Section 3.1. The non-IP encapsulation</td><td> </td><td class="right"> Control packet as described in Section 3.1. The non-IP encapsulation</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> case is described in Section 3.2.</td><td> </td><td class="right"> case is described in Section 3.2.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">3.1. IP Encapsulation of Multipoint BFD</td><td> </td><td class="right">3.1. IP Encapsulation of Multipoint BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp</td><td> </td><td class="right"> [RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MPLS LSP. This document updates Section 5.8 of [RFC8562] regarding</td><td> </td><td class="right"> MPLS LSP. This document updates Section 5.8 of [RFC8562] regarding</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> the selection of the IPv6 destination address:</td><td> </td><td class="right"> the selection of the IPv6 destination address:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0011"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> * <span class="delete">[RFC4291] defines a single IPv6 loopback address. Hence, for</span></td><td> </td><td class="rblock"> * <span class="insert">The sender of an MPLS echo request SHOULD use an address from</span> the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> IPv6,</span> the IPv6 <span class="delete">loopback address ::1/128 SHOULD be used.</span></td><td> </td><td class="rblock"> <span class="insert">Associated Channel</span> IPv6 <span class="insert">Prefix range TBA2/64 Section 7.1.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0012"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> * The sender of an echo request MAY select the IPv6 destination</td><td> </td><td class="rblock"> * The sender of an <span class="insert">MPLS</span> echo request MAY select the IPv6 destination</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> address from the <span class="delete">0:0:0:0:0:FFFF:7F00/104 range.</span></td><td> </td><td class="rblock"> address from the <span class="insert">0:0:0:0:0:ffff:7f00/104 range (see Section 5 of</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> [RFC5952]).</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> The Motivation section [RFC6790] lists several advantages of</td><td> </td><td class="right"> The Motivation section [RFC6790] lists several advantages of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> generating the entropy value by an ingress Label Switching Router</td><td> </td><td class="right"> generating the entropy value by an ingress Label Switching Router</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> (LSR) compared to when a transit LSR infers entropy using the</td><td> </td><td class="right"> (LSR) compared to when a transit LSR infers entropy using the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> information in the MPLS label stack or payload. Thus, this</td><td> </td><td class="right"> information in the MPLS label stack or payload. Thus, this</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> specification further clarifies that:</td><td> </td><td class="right"> specification further clarifies that:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> if multiple alternative paths for the given p2mp LSP Forwarding</td><td> </td><td class="right"> if multiple alternative paths for the given p2mp LSP Forwarding</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the</td><td> </td><td class="right"> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise</td><td> </td><td class="right"> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-5" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-5"><em> page 5, line 4<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-5"><em> page 5, line 15<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> The Motivation section [RFC6790] lists several advantages of</td><td> </td><td class="right"> The Motivation section [RFC6790] lists several advantages of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> generating the entropy value by an ingress Label Switching Router</td><td> </td><td class="right"> generating the entropy value by an ingress Label Switching Router</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> (LSR) compared to when a transit LSR infers entropy using the</td><td> </td><td class="right"> (LSR) compared to when a transit LSR infers entropy using the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> information in the MPLS label stack or payload. Thus, this</td><td> </td><td class="right"> information in the MPLS label stack or payload. Thus, this</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> specification further clarifies that:</td><td> </td><td class="right"> specification further clarifies that:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> if multiple alternative paths for the given p2mp LSP Forwarding</td><td> </td><td class="right"> if multiple alternative paths for the given p2mp LSP Forwarding</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the</td><td> </td><td class="right"> Equivalence Class (FEC) exist, the MultipointHead SHOULD use the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise</td><td> </td><td class="right"> Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> those particular alternative paths;</td><td> </td><td class="right"> those particular alternative paths;</td><td class="lineno"></td></tr>
<tr id="diff0013"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> </span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> or the MultipointHead MAY use the UDP port number to possibly</td><td> </td><td class="right"> or the MultipointHead MAY use the UDP port number to possibly</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> exercise those particular alternate paths.</td><td> </td><td class="right"> exercise those particular alternate paths.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">3.2. Non-IP Encapsulation of Multipoint BFD</td><td> </td><td class="right">3.2. Non-IP Encapsulation of Multipoint BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> In some environments, the overhead of extra IP/UDP encapsulations may</td><td> </td><td class="right"> In some environments, the overhead of extra IP/UDP encapsulations may</td><td class="lineno"></td></tr>
<tr id="diff0014"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> be considered burdensome, making the use of more compact <span class="delete">G-ACh</span></td><td> </td><td class="rblock"> be considered burdensome, making the use of more compact <span class="insert">Generic</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> encapsulation attractive. Also, the validation of the IP/UDP</td><td> </td><td class="rblock"><span class="insert"> Associated Channel (G-ACh) ([RFC5586])</span> encapsulation attractive.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> encapsulation of a BFD Control packet in a p2mp BFD session may fail</td><td> </td><td class="rblock"> Also, the validation of the IP/UDP encapsulation of a BFD Control</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> because of a problem related to neither the MPLS label stack nor to</td><td> </td><td class="rblock"> packet in a p2mp BFD session may fail because of a problem related to</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP</td><td> </td><td class="rblock"> neither the MPLS label stack nor to BFD. Avoiding unnecessary</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> improves the accuracy of the correlation of the detected failure and</td><td> </td><td class="rblock"> encapsulation of p2mp BFD over an MPLS LSP improves the accuracy of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over</td><td> </td><td class="rblock"> the correlation of the detected failure and defect in MPLS LSP.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> p2mp MPLS LSP (shown in Figure 1) MUST use <span class="delete">Generic Associated Channel</span></td><td> </td><td class="rblock"> </td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> (G-ACh)</span> Label (GAL) (see [RFC5586]) at the bottom of the label stack</td><td> </td><td class="rblock"> <span class="insert">If a BFD Control packet in PW-ACH encapsulation (without IP/UDP</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> followed by an Associated Channel Header (ACH). If a BFD Control</td><td> </td><td class="rblock"><span class="insert"> Headers) is to be used in ACH, an implementation would not be able to</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> packet in PW-ACH encapsulation (without IP/UDP Headers) is to be used</td><td> </td><td class="rblock"><span class="insert"> verify the identity of the MultipointHead and, as a result, will not</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> in ACH, an implementation would not be able to verify the identity of</td><td> </td><td class="rblock"><span class="insert"> properly demultiplex BFD packets. Hence, a new channel type value is</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> the MultipointHead and, as a result, will not properly demultiplex</td><td> </td><td class="rblock"><span class="insert"> needed.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> BFD packets. Hence, a new channel type value is needed. The Channel</td><td> </td><td class="rblock"> </td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Type field in ACH MUST be set to Multipoint BFD Session (TBA1) value</td><td> </td><td class="rblock"> Non-IP encapsulation for multipoint BFD over p2mp MPLS LSP (shown in</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> (Section <span class="delete">7).</span> To provide the identity of the MultipointHead for the</td><td> </td><td class="rblock"> Figure 1) MUST use <span class="insert">G-ACh</span> Label (GAL) (see [RFC5586]) at the bottom of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> particular multipoint BFD session, a Source Address TLV, as defined</td><td> </td><td class="rblock"> the label stack followed by an Associated Channel Header (ACH). If a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> in Section 4.1 [RFC7212], MUST immediately follow a BFD Control</td><td> </td><td class="rblock"> BFD Control packet in PW-ACH encapsulation (without IP/UDP Headers)</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> message. The use of other TLVs <span class="delete">defined in Section 4 of [RFC7212]</span> is</td><td> </td><td class="rblock"> is to be used in ACH, an implementation would not be able to verify</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> outside the scope of this document.</td><td> </td><td class="rblock"> the identity of the MultipointHead and, as a result, will not</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> properly demultiplex BFD packets. Hence, a new channel type value is</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> needed. The Channel Type field in ACH MUST be set to Multipoint BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> Session (TBA1) value (Section <span class="insert">7.2).</span> To provide the identity of the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> MultipointHead for the particular multipoint BFD session, a Source</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> Address TLV, as defined in Section 4.1 <span class="insert">of</span> [RFC7212], MUST immediately</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> follow a BFD Control message. The use of other TLVs is outside the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> scope of this document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 0 1 2 3</td><td> </td><td class="right"> 0 1 2 3</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</td><td> </td><td class="right"> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | LSP Label | TC |S| TTL |</td><td> </td><td class="right"> | LSP Label | TC |S| TTL |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | GAL | TC |1| TTL |</td><td> </td><td class="right"> | GAL | TC |1| TTL |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr id="diff0015"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> |0 0 0 1|Version| <span class="delete">Reserved</span> | Channel Type = TBA1 |</td><td> </td><td class="rblock"> |0 0 0 1|Version| <span class="insert"> Flags </span> | Channel Type = TBA1 |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> ~ BFD Control Message ~</td><td> </td><td class="right"> ~ BFD Control Message ~</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | Type=0 | Reserved | Length |</td><td> </td><td class="right"> | Type=0 | Reserved | Length |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr id="diff0016"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> | <span class="delete">Reserved (16 bits) | Address Family (16 bits)</span> |</td><td> </td><td class="rblock"> | <span class="insert"> Reserved | Address Family </span> |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> ~ Address ~</td><td> </td><td class="right"> ~ Address ~</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td> </td><td class="right"> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Figure 1: Non-IP Encapsulation for Multipoint BFD Over a</td><td> </td><td class="right"> Figure 1: Non-IP Encapsulation for Multipoint BFD Over a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Multicast MPLS LSP</td><td> </td><td class="right"> Multicast MPLS LSP</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0017"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">Fields in Figure 1 are interpreted as follows:</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> * the top three four-octet words as defined in [RFC5586];</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> * the BFD Control Message field is as defined in [RFC5880];</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> * all the remaining fields are as defined in Section 4.1 of</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> [RFC7212].</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">4. Bootstrapping Multipoint BFD</td><td> </td><td class="right">4. Bootstrapping Multipoint BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">4.1. LSP Ping</td><td> </td><td class="right">4.1. LSP Ping</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSP Ping is the part of the on-demand OAM toolset used to detect and</td><td> </td><td class="right"> LSP Ping is the part of the on-demand OAM toolset used to detect and</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> localize defects in the data plane and verify the control plane</td><td> </td><td class="right"> localize defects in the data plane and verify the control plane</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> against the data plane by ensuring that the LSP is mapped to the same</td><td> </td><td class="right"> against the data plane by ensuring that the LSP is mapped to the same</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> FEC at both egress and ingress endpoints.</td><td> </td><td class="right"> FEC at both egress and ingress endpoints.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap</td><td> </td><td class="right"> LSP Ping, as defined in [RFC6425], MAY be used to bootstrap</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MultipointTail. If LSP Ping is used, it MUST include the Target FEC</td><td> </td><td class="right"> MultipointTail. If LSP Ping is used, it MUST include the Target FEC</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case</td><td> </td><td class="right"> TLV and the BFD Discriminator TLV defined in [RFC5884]. For the case</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in</td><td> </td><td class="right"> of p2mp MPLS LSP, the Target FEC TLV MUST use sub-TLVs defined in</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Section 3.1 [RFC6425]. For the case of p2mp SR policy with SR-MPLS</td><td> </td><td class="right"> Section 3.1 [RFC6425]. For the case of p2mp SR policy with SR-MPLS</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> data plane, an implementation of this specification MUST follow</td><td> </td><td class="right"> data plane, an implementation of this specification MUST follow</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> procedures defined in [RFC8287]. Setting the value of Reply Mode</td><td> </td><td class="right"> procedures defined in [RFC8287]. Setting the value of Reply Mode</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap</td><td> </td><td class="right"> field to "Do not reply" [RFC8029] for the LSP Ping to bootstrap</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MultipointTail of the p2mp BFD session is RECOMMENDED. Indeed,</td><td> </td><td class="right"> MultipointTail of the p2mp BFD session is RECOMMENDED. Indeed,</td><td class="lineno"></td></tr>
<tr id="diff0018"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> because BFD over a multipoint network uses BFD Demand mode, the <span class="delete">LSP</span></td><td> </td><td class="rblock"> because BFD over a multipoint network uses BFD Demand mode, the <span class="insert">MPLS</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> echo reply from a tail has no useful information to convey to the</td><td> </td><td class="right"> echo reply from a tail has no useful information to convey to the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> head, unlike in the case of the BFD over a p2p MPLS LSP [RFC5884]. A</td><td> </td><td class="right"> head, unlike in the case of the BFD over a p2p MPLS LSP [RFC5884]. A</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MultipointTail that receives an LSP Ping that includes the BFD</td><td> </td><td class="right"> MultipointTail that receives an LSP Ping that includes the BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Discriminator TLV:</td><td> </td><td class="right"> Discriminator TLV:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> * MUST validate the LSP Ping;</td><td> </td><td class="right"> * MUST validate the LSP Ping;</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> * MUST associate the received BFD Discriminator value with the p2mp</td><td> </td><td class="right"> * MUST associate the received BFD Discriminator value with the p2mp</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> LSP;</td><td> </td><td class="right"> LSP;</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-6" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-6"><em> page 7, line 7<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-6"><em> page 7, line 35<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> at the MultipointHead and all active MultipointTails. The rate of</td><td> </td><td class="right"> at the MultipointHead and all active MultipointTails. The rate of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> generation of these LSP Ping Echo request messages SHOULD be</td><td> </td><td class="right"> generation of these LSP Ping Echo request messages SHOULD be</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> significantly less than the rate of generation of the BFD Control</td><td> </td><td class="right"> significantly less than the rate of generation of the BFD Control</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> packets because LSP Ping requires more processing to validate the</td><td> </td><td class="right"> packets because LSP Ping requires more processing to validate the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> consistency between the data plane and the control plane. An</td><td> </td><td class="right"> consistency between the data plane and the control plane. An</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> implementation MAY provide configuration options to control the rate</td><td> </td><td class="right"> implementation MAY provide configuration options to control the rate</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> of generation of the periodic LSP Ping Echo request messages.</td><td> </td><td class="right"> of generation of the periodic LSP Ping Echo request messages.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">4.2. Control Plane</td><td> </td><td class="right">4.2. Control Plane</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0019"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> The <span class="delete">BGP-BFD</span> Attribute <span class="delete">[RFC9026]</span> MAY be used to bootstrap multipoint</td><td> </td><td class="rblock"> The <span class="insert">BFD Discriminator</span> Attribute MAY be used to bootstrap <span class="insert">a</span> multipoint</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> BFD session on a <span class="delete">tail.</span></td><td> </td><td class="rblock"> BFD session on a <span class="insert">tail, following the format and procedures given in</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Section 3.1.6 of [RFC9026].</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP</td><td> </td><td class="right">5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8562] defined how the BFD Demand mode can be used in multipoint</td><td> </td><td class="right"> [RFC8562] defined how the BFD Demand mode can be used in multipoint</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> networks. When applied in MPLS, procedures specified in [RFC8562]</td><td> </td><td class="right"> networks. When applied in MPLS, procedures specified in [RFC8562]</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> allow an egress LSR to detect a failure of the part of the MPLS p2mp</td><td> </td><td class="right"> allow an egress LSR to detect a failure of the part of the MPLS p2mp</td><td class="lineno"></td></tr>
<tr id="diff0020"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> LSP from the ingress LSR. The ingress LSR is not aware of the state</td><td> </td><td class="rblock"> LSP from the ingress <span class="insert">LSR to that egress</span> LSR. The ingress LSR is not</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562],</td><td> </td><td class="rblock"> aware of the state of the p2mp LSP. [RFC8563], using mechanisms</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> defined an "active tail" behavior. An active tail might notify the</td><td> </td><td class="rblock"> defined in [RFC8562], defined an "active tail" behavior. An active</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> head of the detected failure and responds to a poll sequence</td><td> </td><td class="rblock"> tail might notify the head of the detected failure and responds to a</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> initiated by the head. The first method, referred to as Head</td><td> </td><td class="rblock"> poll sequence initiated by the head. The first method, referred to</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> Notification without Polling, is mentioned in Section 5.2.1</td><td> </td><td class="rblock"> as Head Notification without Polling, is mentioned in Section 5.2.1</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8563], is the simplest of all described in [RFC8563]. The use of</td><td> </td><td class="right"> [RFC8563], is the simplest of all described in [RFC8563]. The use of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> this method in BFD over MPLS p2mp LSP is discussed in this document.</td><td> </td><td class="right"> this method in BFD over MPLS p2mp LSP is discussed in this document.</td><td class="lineno"></td></tr>
<tr id="diff0021"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> </span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Analysis of other methods of a head learning of the state of an MPLS</td><td> </td><td class="right"> Analysis of other methods of a head learning of the state of an MPLS</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> p2mp LSP is outside the scope of this document.</td><td> </td><td class="right"> p2mp LSP is outside the scope of this document.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> As specified in [RFC8563] for the active tail mode, BFD variables</td><td> </td><td class="right"> As specified in [RFC8563] for the active tail mode, BFD variables</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> MUST be as follows:</td><td> </td><td class="right"> MUST be as follows:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> On an ingress LSR:</td><td> </td><td class="right"> On an ingress LSR:</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> * bfd.SessionType is MultipointHead;</td><td> </td><td class="right"> * bfd.SessionType is MultipointHead;</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-7" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-7"><em> page 9, line 22<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-7"><em> page 10, line 4<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> section 4.1 [RFC4687] to avoid congestion in the control plane or the</td><td> </td><td class="right"> section 4.1 [RFC4687] to avoid congestion in the control plane or the</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> data plane caused by the rate of generating BFD Control packets. An</td><td> </td><td class="right"> data plane caused by the rate of generating BFD Control packets. An</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> operator SHOULD consider the amount of extra traffic generated by</td><td> </td><td class="right"> operator SHOULD consider the amount of extra traffic generated by</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> p2mp BFD when selecting the interval at which the MultipointHead will</td><td> </td><td class="right"> p2mp BFD when selecting the interval at which the MultipointHead will</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> transmit BFD Control packets. The operator MAY consider the size of</td><td> </td><td class="right"> transmit BFD Control packets. The operator MAY consider the size of</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> the packet the MultipointHead transmits periodically as using IP/UDP</td><td> </td><td class="right"> the packet the MultipointHead transmits periodically as using IP/UDP</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> encapsulation, which adds up to 28 octets, more than 50% of the BFD</td><td> </td><td class="right"> encapsulation, which adds up to 28 octets, more than 50% of the BFD</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Control packet length, comparing to G-ACh encapsulation.</td><td> </td><td class="right"> Control packet length, comparing to G-ACh encapsulation.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">7. IANA Considerations</td><td> </td><td class="right">7. IANA Considerations</td><td class="lineno"></td></tr>
<tr id="diff0022"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">7.1. IPv6 Address Allocation</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> IANA is requested to allocate an IPv6 TBA2/64 prefix as Associated</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Channel IPv6 Prefix in the "Internet Protocol Version 6 Address</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Space" and add the prefix to the "IANA IPv6 Special Purpose Address</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> Registry".</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">7.2. Multipoint BFD over MPLS LSP Associated Channel Type</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> IANA is requested to allocate value (TBA1) from its MPLS Generalized</td><td> </td><td class="right"> IANA is requested to allocate value (TBA1) from its MPLS Generalized</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Associated Channel (G-ACh) Types registry.</td><td> </td><td class="right"> Associated Channel (G-ACh) Types registry.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +=======+========================+===============+</td><td> </td><td class="right"> +=======+========================+===============+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | Value | Description | Reference |</td><td> </td><td class="right"> | Value | Description | Reference |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +=======+========================+===============+</td><td> </td><td class="right"> +=======+========================+===============+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> | TBA1 | Multipoint BFD Session | This document |</td><td> </td><td class="right"> | TBA1 | Multipoint BFD Session | This document |</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> +-------+------------------------+---------------+</td><td> </td><td class="right"> +-------+------------------------+---------------+</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="part-8" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-8"><em> page 11, line 26<span class="hide"> ¶</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-8"><em> page 12, line 22<span class="hide"> ¶</span></em></a></th><td></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,</td><td> </td><td class="right"> [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Ed., "Bidirectional Forwarding Detection (BFD) for</td><td> </td><td class="right"> Ed., "Bidirectional Forwarding Detection (BFD) for</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,</td><td> </td><td class="right"> Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> April 2019, <https://www.rfc-editor.org/info/rfc8562>.</td><td> </td><td class="right"> April 2019, <https://www.rfc-editor.org/info/rfc8562>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,</td><td> </td><td class="right"> [RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Ed., "Bidirectional Forwarding Detection (BFD) Multipoint</td><td> </td><td class="right"> Ed., "Bidirectional Forwarding Detection (BFD) Multipoint</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,</td><td> </td><td class="right"> Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc8563>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc8563>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0023"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> <span class="insert">[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> "Multicast VPN Fast Upstream Failover", RFC 9026,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> DOI 10.17487/RFC9026, April 2021,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> <https://www.rfc-editor.org/info/rfc9026>.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"> </td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">9.2. Informative References</td><td> </td><td class="right">9.2. Informative References</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing</td><td> </td><td class="right"> [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Architecture", RFC 4291, DOI 10.17487/RFC4291, February</td><td> </td><td class="right"> Architecture", RFC 4291, DOI 10.17487/RFC4291, February</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2006, <https://www.rfc-editor.org/info/rfc4291>.</td><td> </td><td class="right"> 2006, <https://www.rfc-editor.org/info/rfc4291>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,</td><td> </td><td class="right"> [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> "Operations and Management (OAM) Requirements for Point-</td><td> </td><td class="right"> "Operations and Management (OAM) Requirements for Point-</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> to-Multipoint MPLS Networks", RFC 4687,</td><td> </td><td class="right"> to-Multipoint MPLS Networks", RFC 4687,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> DOI 10.17487/RFC4687, September 2006,</td><td> </td><td class="right"> DOI 10.17487/RFC4687, September 2006,</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> <https://www.rfc-editor.org/info/rfc4687>.</td><td> </td><td class="right"> <https://www.rfc-editor.org/info/rfc4687>.</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr id="diff0024"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"> <span class="delete">[RFC9026] Morin, T., Ed., Kebler, R., Ed.,</span> and <span class="delete">G. Mirsky, Ed.,</span></td><td> </td><td class="rblock"> <span class="insert">[RFC5952] Kawamura, S.</span> and <span class="insert">M. Kawashima, "A Recommendation for IPv6</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> "Multicast VPN Fast Upstream Failover",</span> RFC <span class="delete">9026,</span></td><td> </td><td class="rblock"><span class="insert"> Address Text Representation",</span> RFC <span class="insert">5952,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"> DOI <span class="delete">10.17487/RFC9026, April 2021,</span></td><td> </td><td class="rblock"> DOI <span class="insert">10.17487/RFC5952, August 2010,</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="lblock"><span class="delete"> <https://www.rfc-editor.org/info/rfc9026>.</span></td><td> </td><td class="rblock"><span class="insert"> <https://www.rfc-editor.org/info/rfc5952>.</span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left">Authors' Addresses</td><td> </td><td class="right">Authors' Addresses</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Greg Mirsky</td><td> </td><td class="right"> Greg Mirsky</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Ericsson</td><td> </td><td class="right"> Ericsson</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Email: [email protected]</td><td> </td><td class="right"> Email: [email protected]</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Gyan Mishra</td><td> </td><td class="right"> Gyan Mishra</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Verizon Inc.</td><td> </td><td class="right"> Verizon Inc.</td><td class="lineno"></td></tr>
<tr id="diff0025"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> </span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Email: [email protected]</td><td> </td><td class="right"> Email: [email protected]</td><td class="lineno"></td></tr>
<tr id="diff0026"><td></td></tr>
<tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"> </span></td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Donald Eastlake, 3rd</td><td> </td><td class="right"> Donald Eastlake, 3rd</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Independent</td><td> </td><td class="right"> Independent</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> 2386 Panoramic Circle</td><td> </td><td class="right"> 2386 Panoramic Circle</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Apopka, FL 32703</td><td> </td><td class="right"> Apopka, FL 32703</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> United States of America</td><td> </td><td class="right"> United States of America</td><td class="lineno"></td></tr>
<tr><td class="lineno"></td><td class="left"> Email: [email protected]</td><td> </td><td class="right"> Email: [email protected]</td><td class="lineno"></td></tr>
<tr><td></td><td class="left"></td><td> </td><td class="right"></td><td></td></tr>
<tr id="end" bgcolor="gray"><th colspan="5" align="center"> End of changes. 26 change blocks. </th></tr>
<tr class="stats"><td></td><th><i>59 lines changed or deleted</i></th><th><i> </i></th><th><i>102 lines changed or added</i></th><td></td></tr>
<tr><td colspan="5" align="center" class="small"><br/>This html diff was produced by rfcdiff 1.49. The latest version is available from <a href="https://github.com/ietf-tools/rfcdiff" >https://github.com/ietf-tools/rfcdiff</a> </td></tr>
</table>
</body>
</html>