From nobody Sun Jul 25 21:26:57 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4C23A1936; Sun, 25 Jul 2021 21:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNMjL4H7v40g; Sun, 25 Jul 2021 21:26:51 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5B63A1933; Sun, 25 Jul 2021 21:26:50 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id e21so5598624pla.5; Sun, 25 Jul 2021 21:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xzxLP36C1KzrcqgDK60y4vnuMLF23LXE1fas/ieG5e0=; b=Uhq4e8+dEkj3RWGgcEPMXC8fQMVblmSVaGWGaurf4yCg5YJMNhZQXwvQ08gMahA7Ud kiUaWDj5lQj2hus+U67db4QmCjGeJjcMbl8cLndXkfjXGo4iZ9k0wnDGcBQr6S7Xjz24 2jSStrMffSQfa8RbNbPiiARDkdTUnIdicnLh9adSIILb2uTDAvSZFZEnJSSiEoAwBrki Eyst32SqH+ykYNfLY4RhwDLcd+7xnlibUWwfi1mMgDRndpaQZ0KJaHm8bBBGP9g7Vy8b LPUIoFMzqSk0/dcDdX5dd6Ibg9hV0zwutZnnrB/BpraByxgY9v/4XoEsqAzaZHKvGlKN Dq5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xzxLP36C1KzrcqgDK60y4vnuMLF23LXE1fas/ieG5e0=; b=NfgZPPtdXEpZhavCfq1igO2/COVIrVRjxPrwNykFHJnx1Vd3ZlR3hcOotzYowjCIhL IokVsg10lPiFRra5f42W3+clX0iYGCywKmnZzcfgi0YRTpoUJ5aKP8+W1rD/qn6QousR hg/dB5vPRfk+WJb6L7++bj/Od0cNLpXKXN98DYhGQk3nxB3UaxqCNBbh0f7plI2SXROW rkw341cn8AcmjexTRfVzdjb0BGd5yc1O6gOHcU/K8+mjTqN9LNJm4nGQoHDQvrkErGKw FpOERnkGnLzq+486grTZEk9VdjTPEdHMpi3qWJsYweH8tWwYCuAg9Q5mx2zZYTYSmrHA aekA== X-Gm-Message-State: AOAM531/K0KfrNTQ5nFgtDfDHGk9kT5kJKfeJUgOnpJlx7/9MSqtfaXL 8vew45ZpyuproQlJWFBTmc4= X-Google-Smtp-Source: ABdhPJxKCv+vBmItd2j0G0nuRM2op96MHtOJdvVkGZO1+JBk7tGTH1n66vaf4kLGb4KR+AuoBBKOag== X-Received: by 2002:a05:6a00:aca:b029:392:9c79:3a39 with SMTP id c10-20020a056a000acab02903929c793a39mr6937696pfl.57.1627273608647; Sun, 25 Jul 2021 21:26:48 -0700 (PDT) Received: from [192.168.1.133] ([76.21.92.206]) by smtp.gmail.com with ESMTPSA id c24sm41178585pfn.86.2021.07.25.21.26.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jul 2021 21:26:48 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_1DF158B6-1BD9-4B6E-9350-544A4CE26CD7" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Date: Sun, 25 Jul 2021 21:26:46 -0700 In-Reply-To: <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> Cc: draft-ietf-bfd-secure-sequence-numbers@ietf.org, Reshad Rehman , "rtg-bfd@ietf. org" , Alan DeKok To: Jeffrey Haas References: <161523096352.2145.10949026299560929284@ietfa.amsl.com> <106C31C7-4118-4CEE-935A-D0F02183C987@gmail.com> <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 04:26:56 -0000 --Apple-Mail=_1DF158B6-1BD9-4B6E-9350-544A4CE26CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [Putting the thread on the BFD mailing list] Hi Jeff/Alan, I wanted to understand the changes the authors need to make to move the = draft forward. On this thread = , @Jeff stated that you were looking for clarity on the following = statement. Note: The first sequence number can be obtained using the same logic as used in determining Local Discriminator value for the session or by using a random number. For which I believe the consensus is the suggestion from Alan below to = add an authentication section in the first packet that carries the = nonce. Right? See inline for more. > On Apr 6, 2021, at 3:09 AM, Alan DeKok wrote: >=20 > On Apr 5, 2021, at 3:08 PM, Jeffrey Haas wrote: >> BFD needs an increasing sequencing number. But we also are trying to >> get replay protection. What that means is that we likely don't want = to >> start at sequence 1 every time - or we need to have a nonce to make = sure we >> don't get a replay if we do. =20 >>=20 >> The protocol currently doesn't carry anything to use as a nonce. >=20 > Maybe add an authentication section in the first packet, which can = then carry a nonce? >=20 >> As written (see section 3), it's written as a reversible operation, = which >> would be reasonable from a symmetric bit of crypto. But if we're = using a >> hash, I don't believe we get that property. Instead, we have to know = what >> we're expecting in each side and have the next k values computed, = where k is >> in the window of the BFD Detect Multiplier (lost packets maximum). >=20 > Yes. >=20 >> Somewhere in between draft-06 and -07, the text started moving toward >> "symmetric key algorithm" from hash, probably as part of the = clarification >> requests for how the mechanism worked. Likely my request, and I = failed to >> remember that we wanted fast hash rather than reversible. >=20 > It depends on what the goals are, I guess. A cryptographic random = number generator is likely to be much faster than a reversible = encryption method, especially on constrained CPUs. But random number = generators aren't reversible, which is also a useful property. >=20 > The main issue with a strong hash function is that it's a hash, and = isn't intended to generate sequences of numbers. What I understand from this discussion is that the WG feels that rather = than symmetric key algorithm, a hash should be used for computing the = ciphertext (if that is the correct term for computed hash?) that will be = inserted in the sequence number field, and the other end will compare = the computed hash against the next k values it has computed on the = expected sequence numbers within the window of BFD Detect Multiplier. = Did I get that right? Inserting this from the same thread. >=20 >>> If so, getting some text would help a bunch. >>=20 >> I'll see what I can do. >=20 > That'd be great. Alan, could you help us with the text here. >=20 >> That was my impression. Complexity might be worthwhile as long as = the memory >> is constrained. This is going onto linecards with the CPUs that = would >> embarass a lot of people, after all. >=20 > The Blake3 code isn't trivial, and doesn't seem to have fixed-size = memory requirements, unlike MD5 / SHA. >=20 > Looking around, we also have https://tools.ietf.org/html/rfc8937, = which recommends against directly using the output of a PRNG. It = recommends instead a fairly complex scheme, which isn't applicable here. = But perhaps we could do something similar. >=20 > My suggestion would be to do something vaguely like what RFC 8937 = suggests, but with weaker / faster algorithms. >=20 > We could use ISAAC to securely generate a sequence of random numbers. = The first packets exchanged could contain an authentication section = with a nonce. ISAAC would be seeded with a secret key and a nonce, and = would generate a stream of 32-bit cryptographically strong pseudo-random = numbers. >=20 > We could use this output directly, but we might want to go a step = further. We could add a fast hash function to further hide the output = of the random number generator, and also get authentication of the = packet contents. >=20 > i.e. for a packet P, set My-Discriminator to zero, take the random = number X from Isaac, and then calculate Hash(X, P). The output is a = 32-bit number which can go into the discriminator field. >=20 > The other end can set the discriminator to zero, calculate the hash, = and then see if the packet has been authenticated. The benefit here is = that it's authenticating not just the particular sequence from the = random number generator. It is also authenticating the packet. And, = because the packet contains Your-Discriminator, the has would = authenticate the entire sequence of packets. Which seems a desirable = property. >=20 > Either option would be imperfect, but fast and reasonably secure. Not clear on whether we are now trying to define how the nonce should be = calculated, and if that is not getting into implementation level = details.=20 Thanks. >=20 > Alan DeKok. >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_1DF158B6-1BD9-4B6E-9350-544A4CE26CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [Putting the thread on the BFD mailing list]
Hi Jeff/Alan,

I wanted to understand the changes the = authors need to make to move the draft forward.

On this thread, @Jeff stated that you were looking for = clarity on the following statement.

   Note: The =
first sequence number can
   be obtained using the same logic as used in determining Local
   Discriminator value for the session or by using a random =
number.
For which I believe the consensus is the = suggestion from Alan below to add an authentication section in the first = packet that carries the nonce. Right?

See inline for more.

On Apr = 6, 2021, at 3:09 AM, Alan DeKok <aland@freeradius.org> wrote:

On = Apr 5, 2021, at 3:08 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:
BFD needs an = increasing sequencing number.  But we also are trying to
get replay protection.  What that means is that we = likely don't want to
start at sequence 1 every time - or = we need to have a nonce to make sure we
don't get a replay = if we do.  

The protocol currently = doesn't carry anything to use as a nonce.

 Maybe add an authentication section in the first = packet, which can then carry a nonce?

As written (see section = 3), it's written as a reversible operation, which
would be = reasonable from a symmetric bit of crypto.  But if we're using a
hash, I don't believe we get that property.  Instead, we = have to know what
we're expecting in each side and have = the next k values computed, where k is
in the window of = the BFD Detect Multiplier (lost packets maximum).

 Yes.

Somewhere in between = draft-06 and -07, the text started moving toward
"symmetric = key algorithm" from hash, probably as part of the clarification
requests for how the mechanism worked.  Likely my = request, and I failed to
remember that we wanted fast hash = rather than reversible.

=  It depends on what the goals are, I guess.  A cryptographic = random number generator is likely to be much faster than a reversible = encryption method, especially on constrained CPUs.  But random = number generators aren't reversible, which is also a useful property.

 The main issue with a strong hash = function is that it's a hash, and isn't intended to generate sequences = of numbers.

What I understand from this discussion is that the WG = feels that rather than symmetric key algorithm, a hash should be used = for computing the ciphertext (if that is the correct term for computed = hash?) that will be inserted in the sequence number field, and the other = end will compare the computed hash against the next k values it has = computed on the expected sequence numbers within the window of BFD = Detect Multiplier. Did I get that right?

Inserting this from the same thread.


If so, = getting some text would help a bunch.

 I'll see what I can do.

That'd be = great.

Alan, = could you help us with the text here.


That was = my impression.  Complexity might be worthwhile as long as the = memory
is constrained.  This is going onto linecards = with the CPUs that would
embarass a lot of people, after = all.

 The Blake3 code = isn't trivial, and doesn't seem to have fixed-size memory requirements, = unlike MD5 / SHA.

 Looking around, we = also have https://tools.ietf.org/html/rfc8937, which recommends = against directly using the output of a PRNG.  It recommends instead = a fairly complex scheme, which isn't applicable here.  But perhaps = we could do something similar.

 My = suggestion would be to do something vaguely like what RFC 8937 suggests, = but with weaker / faster algorithms.

=  We could use ISAAC to securely generate a sequence of random = numbers.  The first packets exchanged could contain an = authentication section with a nonce.  ISAAC would be seeded with a = secret key and a nonce, and would generate a stream of 32-bit = cryptographically strong pseudo-random numbers.

 We could use this output directly, but we might want = to go a step further.  We could add a fast hash function to further = hide the output of the random number generator, and also get = authentication of the packet contents.

=  i.e. for a packet P, set My-Discriminator to zero, take the random = number X from Isaac, and then calculate Hash(X, P).  The output is = a 32-bit number which can go into the discriminator field.

 The other end can set the discriminator = to zero, calculate the hash, and then see if the packet has been = authenticated.  The benefit here is that it's authenticating not = just the particular sequence from the random number generator.  It = is also authenticating the packet.  And, because the packet = contains Your-Discriminator, the has would authenticate the entire = sequence of packets.  Which seems a desirable property.

 Either option would be imperfect, but = fast and reasonably secure.

Not clear = on whether we are now trying to define how the nonce should be = calculated, and if that is not getting into implementation level = details. 

Thanks.


 Alan DeKok.


Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_1DF158B6-1BD9-4B6E-9350-544A4CE26CD7-- From nobody Mon Jul 26 05:08:11 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956B53A0DED; Mon, 26 Jul 2021 05:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNj73fSBaIDN; Mon, 26 Jul 2021 05:08:08 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CA13A0DEB; Mon, 26 Jul 2021 05:08:07 -0700 (PDT) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id D688812F; Mon, 26 Jul 2021 12:08:04 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=freeradius.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt From: Alan DeKok In-Reply-To: Date: Mon, 26 Jul 2021 08:08:03 -0400 Cc: Jeffrey Haas , draft-ietf-bfd-secure-sequence-numbers@ietf.org, Reshad Rehman , "rtg-bfd@ietf. org" Content-Transfer-Encoding: quoted-printable Message-Id: <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> References: <161523096352.2145.10949026299560929284@ietfa.amsl.com> <106C31C7-4118-4CEE-935A-D0F02183C987@gmail.com> <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 12:08:10 -0000 On Jul 26, 2021, at 12:26 AM, Mahesh Jethanandani = wrote: > I wanted to understand the changes the authors need to make to move = the draft forward. >=20 > On this thread, @Jeff stated that you were looking for clarity on the = following statement. >=20 > Note: The first sequence number can > be obtained using the same logic as used in determining Local > Discriminator value for the session or by using a random number. >=20 > For which I believe the consensus is the suggestion from Alan below to = add an authentication section in the first packet that carries the = nonce. Right? I think that makes sense. > What I understand from this discussion is that the WG feels that = rather than symmetric key algorithm, a hash should be used for computing = the ciphertext (if that is the correct term for computed hash?) that = will be inserted in the sequence number field, and the other end will = compare the computed hash against the next k values it has computed on = the expected sequence numbers within the window of BFD Detect = Multiplier. Did I get that right? Yes.=20 >> We could use this output directly, but we might want to go a step = further. We could add a fast hash function to further hide the output = of the random number generator, and also get authentication of the = packet contents. >>=20 >> i.e. for a packet P, set My-Discriminator to zero, take the random = number X from Isaac, and then calculate Hash(X, P). The output is a = 32-bit number which can go into the discriminator field. >>=20 >> The other end can set the discriminator to zero, calculate the hash, = and then see if the packet has been authenticated. The benefit here is = that it's authenticating not just the particular sequence from the = random number generator. It is also authenticating the packet. And, = because the packet contains Your-Discriminator, the has would = authenticate the entire sequence of packets. Which seems a desirable = property. >>=20 >> Either option would be imperfect, but fast and reasonably secure. >=20 > Not clear on whether we are now trying to define how the nonce should = be calculated, and if that is not getting into implementation level = details.=20 If the secure sequence numbers are based on a particular algorithm, = then that algorithm should be documented. If we have a fast hash and CSPRNG, we can combine the two to get = secure sequence numbers. Plus, we may also leverage this to get the = entire packet signed, which might be a desirable property. Alan DeKok. From nobody Mon Jul 26 07:15:00 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ED13A1573; Mon, 26 Jul 2021 07:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai4xj27KXFt8; Mon, 26 Jul 2021 07:14:57 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA9F23A156F; Mon, 26 Jul 2021 07:14:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 8FC021E1CD; Mon, 26 Jul 2021 10:14:55 -0400 (EDT) Date: Mon, 26 Jul 2021 10:14:55 -0400 From: Jeffrey Haas To: Alan DeKok Cc: Mahesh Jethanandani , draft-ietf-bfd-secure-sequence-numbers@ietf.org, Reshad Rehman , "rtg-bfd@ietf. org" Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Message-ID: <20210726141455.GA32584@pfrc.org> References: <106C31C7-4118-4CEE-935A-D0F02183C987@gmail.com> <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 14:14:59 -0000 Alan, Mahesh, Let's go back to base expectations. Right now, the base BFD specification leverages HMAC MD5 or SHA-1 for its security. The security mechanism is on every packet. Prior measurements have shown that for the desired protocol rates for failure detection that even those older mechanisms are enough of a CPU hit that people don't care to run them. There is a push by the security community to deprecate those mechanisms for various SHA-2 mechanisms which would simply make the problem worse. The optimizing-authentication mechanism perhaps offers a way out of this by saying we'll only provide that level of authentication on packets during important state changes, and periodically on the regular stream of packets. However, that leaves the protocol in a state where if it was totally unauthenticated (the NULL authentication mechanism), an active attacker could keep a session up when it was actually down. (The severity of this attack on operations is perhaps a different discussion, but it concerns people in the security disciplines.) The original idea for this proposal was there existed light-weight hash functions that would provide reasonable and fast operations that could be used for the periodic protocol transmissions that didn't require strong authentication. So, what is needed: - A mechanism that can be used with the optimizing authentication extension. - That is light weight enough to justify it as being better than existing HMAC MD5 for periodic transmissions. - The value of which could be encoded in the BFD Authentication section. Recall that the challenge around BFD is the protocol contains very little content. It will largely be cleartext. And most difficult for the setup, Discriminators are not always negotiated a priori, although some BFD forms will do such negotiation using a bootstrapping protocol. Requirements-wise, it's not necessarily required that the function in question be "simple", only fast. The procedure in draft-08 is rather muddled and unclear how it would properly accomplish the general goals. In particular, even in the absence of a specific hash function as an input the procedure applied to the BFD PDUs isn't terribly clear. --- Here's what I think we're looking at, in general: The "Mandatory Section" described in RFC 5880 is the first part of a BFD packet. This is followed by an optional "Authentication Section". Section 4.4 provides an example of the Meticulous Keyed SHA1 packet. This contains a Sequence Number which is monotonically increasing as part of the protocol operation. For meticulous mode, it increases for each packet. The hash over the packet and the expected sequence number along with the key and any necessary nonce yields a value H. This value, H, needs to go into the BFD authentication section in some fashion for its extension. The secure sequence number draft suggests that it goes into the sequence number field that is transmitted in the packet. Upon receipt, the BFD neighbor needs to verify the packet. As currently written, the secure sequence number draft seems to suggest a reversible mechanism from which the hash packet may be reversed and the sequence number determined. This sequence number is required by the validation procedure for BFD sessions. It's my belief that the form of cryptographic hash function we're discussing is a one-way function. If it is a one-way function, the receiving procedure can't be to "reverse" it. At best, it can take the PDU as input, try the BFD Detection Multiplier number (valid packet sequence window), then see if a hash that is computed on the input PDU with the possible sequence numbers yields the received sequence number, H, in the PDU. This means that the benefit for the feature would require a function that can be run on a window of packets for predicted inputs and generate the pool of next expected sequence numbers. Procedure would also need to be crafted for allowing the hashed values to be switched to once the optimizing authentication procedure would have us switch back to the NULL procedure. -- Jeff On Mon, Jul 26, 2021 at 08:08:03AM -0400, Alan DeKok wrote: > On Jul 26, 2021, at 12:26 AM, Mahesh Jethanandani wrote: > > I wanted to understand the changes the authors need to make to move the draft forward. > > > > On this thread, @Jeff stated that you were looking for clarity on the following statement. > > > > Note: The first sequence number can > > be obtained using the same logic as used in determining Local > > Discriminator value for the session or by using a random number. > > > > For which I believe the consensus is the suggestion from Alan below to add an authentication section in the first packet that carries the nonce. Right? > > I think that makes sense. > > > What I understand from this discussion is that the WG feels that rather than symmetric key algorithm, a hash should be used for computing the ciphertext (if that is the correct term for computed hash?) that will be inserted in the sequence number field, and the other end will compare the computed hash against the next k values it has computed on the expected sequence numbers within the window of BFD Detect Multiplier. Did I get that right? > > Yes. > > >> We could use this output directly, but we might want to go a step further. We could add a fast hash function to further hide the output of the random number generator, and also get authentication of the packet contents. > >> > >> i.e. for a packet P, set My-Discriminator to zero, take the random number X from Isaac, and then calculate Hash(X, P). The output is a 32-bit number which can go into the discriminator field. > >> > >> The other end can set the discriminator to zero, calculate the hash, and then see if the packet has been authenticated. The benefit here is that it's authenticating not just the particular sequence from the random number generator. It is also authenticating the packet. And, because the packet contains Your-Discriminator, the has would authenticate the entire sequence of packets. Which seems a desirable property. > >> > >> Either option would be imperfect, but fast and reasonably secure. > > > > Not clear on whether we are now trying to define how the nonce should be calculated, and if that is not getting into implementation level details. > > If the secure sequence numbers are based on a particular algorithm, then that algorithm should be documented. > > If we have a fast hash and CSPRNG, we can combine the two to get secure sequence numbers. Plus, we may also leverage this to get the entire packet signed, which might be a desirable property. > > Alan DeKok. From nobody Mon Jul 26 07:35:11 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162E13A1651; Mon, 26 Jul 2021 07:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYseowwAaCh5; Mon, 26 Jul 2021 07:35:05 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC1B3A164F; Mon, 26 Jul 2021 07:35:05 -0700 (PDT) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 3037C168; Mon, 26 Jul 2021 14:35:02 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=freeradius.org Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt From: Alan DeKok In-Reply-To: <20210726141455.GA32584@pfrc.org> Date: Mon, 26 Jul 2021 10:35:01 -0400 Cc: "rtg-bfd@ietf. org" , Reshad Rehman , draft-ietf-bfd-secure-sequence-numbers@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> References: <106C31C7-4118-4CEE-935A-D0F02183C987@gmail.com> <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> <20210726141455.GA32584@pfrc.org> To: Jeffrey Haas X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 14:35:10 -0000 On Jul 26, 2021, at 10:14 AM, Jeffrey Haas wrote: > So, what is needed: > - A mechanism that can be used with the optimizing authentication = extension. > - That is light weight enough to justify it as being better than = existing > HMAC MD5 for periodic transmissions. > - The value of which could be encoded in the BFD Authentication = section. That should be possible. > Upon receipt, the BFD neighbor needs to verify the packet. As = currently > written, the secure sequence number draft seems to suggest a = reversible > mechanism from which the hash packet may be reversed and the sequence = number > determined. This sequence number is required by the validation = procedure > for BFD sessions. It's my belief that the form of cryptographic hash > function we're discussing is a one-way function. Yes. > If it is a one-way function, the receiving procedure can't be to = "reverse" > it. At best, it can take the PDU as input, try the BFD Detection = Multiplier > number (valid packet sequence window), then see if a hash that is = computed > on the input PDU with the possible sequence numbers yields the = received > sequence number, H, in the PDU. Yes. > This means that the benefit for the feature would require a function = that > can be run on a window of packets for predicted inputs and generate = the pool > of next expected sequence numbers. Yes. I think a cryptographic random number generator here is likely OK. = Those are usually simple, and fast. The system can be seeded with a = strong secret, or maybe hash of a secret and other information. My suggestion to calculate a hash over the packet is that it prevents = certain kinds of attacks. i.e. an attacker could take packet X, and = sequence number Y, and put the two together, to spoof / forge state. Fixing that requires that the sequence number is somehow tied to a = particular packet. Alan DeKok. From nobody Mon Jul 26 07:48:32 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1753A174B; Mon, 26 Jul 2021 07:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRuTm5vL0KSj; Mon, 26 Jul 2021 07:48:28 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEC13A173B; Mon, 26 Jul 2021 07:48:28 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2DCB41E1CD; Mon, 26 Jul 2021 10:48:27 -0400 (EDT) Date: Mon, 26 Jul 2021 10:48:26 -0400 From: Jeffrey Haas To: Alan DeKok Cc: "rtg-bfd@ietf. org" , Reshad Rehman , draft-ietf-bfd-secure-sequence-numbers@ietf.org Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Message-ID: <20210726144826.GB32584@pfrc.org> References: <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> <20210726141455.GA32584@pfrc.org> <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 14:48:30 -0000 Alan, On Mon, Jul 26, 2021 at 10:35:01AM -0400, Alan DeKok wrote: > > That should be possible. [...] > Yes. [...] > Yes. > > > This means that the benefit for the feature would require a function that > > can be run on a window of packets for predicted inputs and generate the pool > > of next expected sequence numbers. > > Yes. > > I think a cryptographic random number generator here is likely OK. Those are usually simple, and fast. The system can be seeded with a strong secret, or maybe hash of a secret and other information. > > My suggestion to calculate a hash over the packet is that it prevents certain kinds of attacks. i.e. an attacker could take packet X, and sequence number Y, and put the two together, to spoof / forge state. > > Fixing that requires that the sequence number is somehow tied to a particular packet. I don't dispute that these things are possible. What's being requested is that our specifications have some specificity and a proposal be made for a suitable mechanism and how it integrates into BFD. :-) In any case, you've minimally confirmed that the current text in the secure-sequence numbers draft is misleading in suggesting a reversible operation. The procedural text there thus needs work to incorporate the points discussed. -- Jeff From nobody Mon Jul 26 16:25:38 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CEF3A0A34; Mon, 26 Jul 2021 16:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99y6vfYZWXTW; Mon, 26 Jul 2021 16:25:31 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D09A3A0A33; Mon, 26 Jul 2021 16:25:31 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id d1so6311906pll.1; Mon, 26 Jul 2021 16:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=b5g8CScSxLA7tyPmXcHJoZIpLmh2pb7FEhjtqFaIoAE=; b=OLxD+bJvZAkLlwvBz+3/hUO6hUM7azX0oqnmpg2sIBOVBOdXyE3ohD7lRApIYZnQDt ewLfgDcCvhJlY7eDYE5Xtj3rrw8jPp8ULQM66v9sM4x63nOVSm/UOvSjAOzurtaQzPiW SZMJse335Ng0ZNyAseit58nr6CE7kb/sqdFJJ03XEKGgLWO8hkwX2qlSRiLwb+NVZiAJ 002w4PN+yMZA5Hjt9WJtH89I0MLyezH3VVBz1hiockEfPgBI0aU7W+YSFlaLfoLz7iAW X0HeDeFGhN7QbGF7b8VnEBOQidvQohZfnJ2nr3VT0soCmOXGC5/p5/mPEm43eCsgckC+ FK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=b5g8CScSxLA7tyPmXcHJoZIpLmh2pb7FEhjtqFaIoAE=; b=CmKAHetj88yii3cCyyb5h8mnFj9QRQJt+T6vA3+uaA1xdE9+0mK7nZ6RuQ5l2Ggkg2 KaPiQP0URb8JwRzh8nvetP0gkJ0+NM0PYfj9mh7ncwAYKS2dFqOzdA+dV9XEZV3qA5hU 6tflMazWShZqLTSi4/RTLybj3IzXMRbLTqPT/QvOgTEitO6g3ThnNPivH4HBHg5xaHRH d5pV63a0L2zQDNr30WeTlh7cmfaieSey5JVl6j8/YIARlDljUKo2+vPQ0g8gHPsHVWXq Ydo/TCBKfq9mmrutFu5X0wMUYfxfBMGTeqTQk3FLXpFwjDcGKkk54X0HVo4FMHntDqAY yjxg== X-Gm-Message-State: AOAM5338mGrXt/QFHPtOg2hpQzp3bbWYS0MRLXtVu5ILuRJ+uejTI/pS sdmJ+L70kipcWGqQVcA/f4Tdl3O2uN2Ffg== X-Google-Smtp-Source: ABdhPJxrmegJd+EXVe5gyFY9/RfJ/WOSAnRJO/6HZeebNuRPZSudTzy9tBXxgKAf/xEYt2RZ8aNeCg== X-Received: by 2002:a63:5a42:: with SMTP id k2mr16196324pgm.301.1627341928981; Mon, 26 Jul 2021 16:25:28 -0700 (PDT) Received: from [192.168.1.133] ([76.21.92.206]) by smtp.gmail.com with ESMTPSA id p53sm1129900pfw.168.2021.07.26.16.25.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jul 2021 16:25:28 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <173DA06B-21E7-42A4-8EFF-82AA3D84B338@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7B722D92-2663-4530-965F-B7B32F9B65B8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: I-D Action: draft-ietf-bfd-secure-sequence-numbers-08.txt Date: Mon, 26 Jul 2021 16:25:25 -0700 In-Reply-To: <20210726144826.GB32584@pfrc.org> Cc: Alan DeKok , "rtg-bfd@ietf. org" , Reshad Rehman , draft-ietf-bfd-secure-sequence-numbers@ietf.org To: Jeffrey Haas References: <20210405171412.GB12257@pfrc.org> <4831ADD8-6E8D-4CDD-966F-B273A3AF45C5@freeradius.org> <20210405184656.GE12257@pfrc.org> <468C7D1D-7BE2-4759-9D81-0E18725FCA90@freeradius.org> <20210405190821.GF12257@pfrc.org> <14A4DD6D-7002-45A9-8FE4-42B512E97318@freeradius.org> <096BC9E7-8877-4EF3-A94B-394AFE0E76E7@freeradius.org> <20210726141455.GA32584@pfrc.org> <211EC22C-F4AB-4FE6-98AB-511C5CE4EB8B@freeradius.org> <20210726144826.GB32584@pfrc.org> X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 23:25:36 -0000 --Apple-Mail=_7B722D92-2663-4530-965F-B7B32F9B65B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeff, > On Jul 26, 2021, at 7:48 AM, Jeffrey Haas wrote: >=20 > What's being requested is that our specifications have some = specificity and > a proposal be made for a suitable mechanism and how it integrates into = BFD. > :-) Here are the set of changes that I propose we make to the draft to bring = the specificity that you are requesting. For the introductory part of = the document there is no reference to the method being applied to come = up with a sequence number. It just states that the sequence number = inserted is not the monotonically increasing sequence number. As such no = changes are needed there. The change therefore starts in Section 3 - Theory of operation. There = are two changes that I see. One has to do with carrying of nonce in the = first packet, and the other has to do with existing text in the section. For the carrying of nonce in the first packet, Alan has already = suggested adding the authentication section in the first packet. We will = add text to that effect. As far as the existing text in the section is concerned, we will replace = reference to =E2=80=9Csymmetric key algorithm=E2=80=9D and =E2=80=9Csymmet= ric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D. As a result, the = sender will include a ciphertext that is a 32-bit hash computed using = one of the algorithms Alan has suggested using a shared key (that is not = necessarily symmetric) and inserted in-lieu of the sequence number of = the packet. Yes, this draft is about obfuscation of the sequence number = field of the packet, not the entire packet. On reception of the BFD = Control packet, the receiver instead of decrypting the ciphertext = inserted in-place of the sequence number, will instead compare the = ciphertext to pre-computed set of hashes using the same shared key, on = the next k expected sequence numbers that are within the BFD Detect = Multiplier range. If there is a match, the receiver will replace the = ciphertext in the packet with the expected sequence number and pass the = frame for further processing. In the case there is no match, it will = drop the packet. There are some similar updates to the Security Considerations section to = replace =E2=80=9Csymmetric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D.= Are these set of changes enough to bring the specificity that you are = looking for? Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_7B722D92-2663-4530-965F-B7B32F9B65B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Jeff,


On Jul 26, 2021, at 7:48 AM, = Jeffrey Haas <jhaas@pfrc.org> wrote:

What's being requested is that = our specifications have some specificity and
a proposal be made for a = suitable mechanism and how it integrates into BFD.
:-)

Here are the set of changes that I propose we make = to the draft to bring the specificity that you are requesting. For the = introductory part of the document there is no reference to the method = being applied to come up with a sequence number. It just states that the = sequence number inserted is not the monotonically increasing sequence = number. As such no changes are needed there.

The change therefore starts in Section 3 - Theory = of operation. There are two changes that I see. One has to do with = carrying of nonce in the first packet, and the other has to do with = existing text in the section.

For = the carrying of nonce in the first packet, Alan has already suggested = adding the authentication section in the first packet. We will add text = to that effect.

As far as the = existing text in the section is concerned, we will replace reference to = =E2=80=9Csymmetric key algorithm=E2=80=9D and =E2=80=9Csymmetric = algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D. As a result, the sender = will include a ciphertext that is a 32-bit hash computed using one of = the algorithms Alan has suggested using a shared key (that is not = necessarily symmetric) and inserted in-lieu of the sequence number of = the packet. Yes, this draft is about obfuscation of the sequence number = field of the packet, not the entire packet.  On reception of the = BFD Control packet, the receiver instead of decrypting the ciphertext = inserted in-place of the sequence number, will instead compare the = ciphertext to pre-computed set of hashes using the same shared key, on = the next k expected sequence numbers that are within the BFD Detect = Multiplier range. If there is a match, the receiver will replace the = ciphertext in the packet with the expected sequence number and pass the = frame for further processing. In the case there is no match, it will = drop the packet.

There are some = similar updates to the Security Considerations section to replace = =E2=80=9Csymmetric algorithm=E2=80=9D with =E2=80=9Chash=E2=80=9D.

Are these set of changes enough to bring = the specificity that you are looking for?

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_7B722D92-2663-4530-965F-B7B32F9B65B8-- From nobody Tue Jul 27 07:45:02 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262113A060A; Tue, 27 Jul 2021 07:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjGHSBf5Jmay; Tue, 27 Jul 2021 07:44:56 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10109.outbound.protection.outlook.com [40.107.1.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC09F3A0652; Tue, 27 Jul 2021 07:44:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H6DsmeoCRkS4sGmJOvnBKD5CxuNUvyzMNHBfuljkZwkfzJ4w6ANorkLG+CzIVIPgJ0dVyrGtazXI+eT/zg8UXxstWSwl5c8+McrgcijZkDW82OHc8MudKns8gyInunzVO+URZj6QpxMuHA9+hNF16HEt3DxHiVFf0J0B1qlNDbQT0ETLnLnQV1ptGoI6onECBf2WqlgKJH2ySOx6wreEFcC1dUgMbqyqScUpRupEkQYift9ewtC76TxOCWFksRmhysQJOSW9mvlOCaDie/uJ8Xg22/sbzP0cdySgCz7aCn80iYZbbQ76bYxMIjZhP5GXWvLzAG+DeZbjqRbcaNwqrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXdBDqr7mSB3ss8DMT9wWOFGOtvqP5lk6FH0vMQfJHA=; b=oNvhcm5wPI9L+Bdjjol0CI2b8Wl6S1IPlG1lSo7KXNEHCn9J0tEw4wQgC+s0xH4fOL356yFzgjNlOnvul7UhXkxOVOPMxtAZoc08F3aw/ajIA6EjBpaTnE3LAwSgGEKr0Bz6APciWrwND38PKOq4/rtsoAKqwUjXoF6431grsp/jtZAEfaT/DnfvLtVn6g1mAKuTff6Ex8CfZkFbSrCe45z0gmLH5Bq0Gyr3oT43Pzz89pfZqlvx3Z+uaLEokVNB/0MUr3KWV9QL20uIj3JJ7ZbIlm3Qx43Q6YM+gvyUbozbwH+gBbauqMOsCHmvS/iVrwmcIUwiJ2e5TYy3rbfSpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXdBDqr7mSB3ss8DMT9wWOFGOtvqP5lk6FH0vMQfJHA=; b=ITWMYtAvfg4PJ/VwnvH+MeS9ZxUVTsKgUynQrZjd1X9JE4F12Qj2hB//9FKpXauDZxAfK4d0kjpi8MgTutdmAGkcWXO6iaF2rsPLgeLyoBmN4BZjHvU/1yO7JwgVmONM1PFqjLMPB1JugjhFsov+yWcyEr6P1K9+ibaFVxwsvzc= Received: from DB7PR07MB5546.eurprd07.prod.outlook.com (2603:10a6:10:73::23) by DB7PR07MB5029.eurprd07.prod.outlook.com (2603:10a6:10:59::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.14; Tue, 27 Jul 2021 14:44:52 +0000 Received: from DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::51be:6d5a:9b3f:ac8c]) by DB7PR07MB5546.eurprd07.prod.outlook.com ([fe80::51be:6d5a:9b3f:ac8c%5]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 14:44:52 +0000 From: tom petch To: Reshad Rahman , Yingzhen Qu CC: "lsr@ietf.org" , "rtg-bfd@ietf. org" , "martin.vigoureux@nokia.com" Subject: Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Topic: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Index: AQHXHPHjA5GB8834uUmUYEtEKv/9BKqPwhnlgACnXACAXPVdgIBqUeHW Date: Tue, 27 Jul 2021 14:44:52 +0000 Message-ID: References: <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93.ref@yahoo.com> <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93@yahoo.com> <40AB32BD-3138-460F-B385-B8BA6D1EA8FB@gmail.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52b884bb-ddf3-4e4b-36fe-08d9510d17e8 x-ms-traffictypediagnostic: DB7PR07MB5029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rqGDEF/kCN0DtbtgbRldciBB3xwY7LxScQRJ0/TKn/QO4wYen6H8OvoJTFl2ep181Q7AzAkcBo8H4Vt7zrckbiS6xVuwM65CpUpV3UGagGq8pT0A+7ZKBMxJKCrlYZJZ77+76bO+q3lXDNRPdSM3JNZnRFBn/ABbDjYo+crPCUqcPVP3cN4pM2ufnrZhnlcqywEcfnP4hJWJO2K78YB2wuJBJHAMp8g2Uo1xhTvIjrNfZ7d4tpFtujvCHSja0iSeGj1JP01hAa9u0eEV6/F/ua9xMXOm6aYEpeszB6f3Iz44Igti0bosuZo0NkWOjEhkP4h2VUsFy7zUmn/e8c3cc3/+4dsJsFklQ08JHYI3VP/vLLJgwIPO6bXWqvPKSYfGtvrNcCT7VYjj1Fl1GiO9eTjVpfoCou8LSGQpPEooChlLhddoB/FFRyGHXrkvdxoBfwbJ5hRCv25wwnnbs9F2Ljk0oVjtlwAxV30VRsebdnrWyIBJOwY9l4InqP5fXZZiDd6GVBdDpjHuLlK0yeYOJlIdZ6CHoX7mTvNIgKE7cgjXJBdkA4w32cgHvx3xqkX3k7bczhxebxjhVcB5m5McSiUpNNaEoPrzoFGVyD5WsMvIfuC6532n5EbokZzn6Srrafn4AicY8XUqO15uYfAWaBggmlQ0ys2iKCo4YPJC6qStPO099UynSgItRUaksK8Z2Tqszt6T89/4RHA/6Hpqv+9OImqkqB2WJaEUBtrkFzxjGlB2eiAEwOhuTzCagj4jAhpg1wfDpCUdT4+Zft/0P2MHNbB8Qf7HASRs8OfWr8Ci/R3CM8RE3cK7jPtsHDYL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5546.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(366004)(396003)(346002)(39860400002)(54906003)(2906002)(86362001)(33656002)(478600001)(38100700002)(186003)(316002)(53546011)(6506007)(66476007)(26005)(7696005)(110136005)(9686003)(55016002)(66446008)(5660300002)(4326008)(52536014)(8676002)(8936002)(71200400001)(91956017)(966005)(76116006)(66946007)(66556008)(64756008)(122000001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cHk1TVFMQUp5KzdoUlM2UmJ5UU5sbWN0enM2MU1CakVka1NzOUFCWUtrSTN0?= =?utf-8?B?alJYVGVjT3VNQUd4ZDMzREt3bStDamlaWVJmZFNjaXYxcEVOOG0vc2hkYW9C?= =?utf-8?B?WDFFVEJWWXdVMkhSY2Y4UWwzbjBLdExDNy9HdUIxSHRYMjZSemJ1dUNSRWZk?= =?utf-8?B?bHBUZGJhNE9KOTBTWlhzanBmMWNiQjdOQ3VLLzBISFh5RUltWEhxNUx6Tlk1?= =?utf-8?B?KzFCZ09DYi9iWTRBWHlXYmliWVBic09UY3N5T0R5S0JxVS9wVDFJRWI0aXYx?= =?utf-8?B?aHdKWndEaSt4YzB3NTJRaW1FTzdkRy9remw1eGxET2VyeUZIWXlSRVZGbm9V?= =?utf-8?B?ZlY0WGs2bEpBcEY0ODVkWk9sN2xXcmtzRUxWbEpIYlg5VXRNT1ZFK2N3Rmhh?= =?utf-8?B?YUw5QUhjOHVsdlFZVWlwdHBuVnpEa0FXck1VU0I0VWFlZEVOcDhkVXM1UzFW?= =?utf-8?B?eUJSSnk5a3k1ODBwSHJ2blBWSkNpNVBEQ01CRm9INnNIZlBzRVI3SUs3czZD?= =?utf-8?B?TnhDNWFINjg1SkM2MTVwZ2c2ajZFWi91eWdtOXRkdGhzbVBWUElISUF3Y3VB?= =?utf-8?B?Yk1rc3pOdEJiVzlWSW1ZVWdqMjJmWEI4ckNZRitaeGswa01aVnFYVFFpbkZx?= =?utf-8?B?WGRBQWFmc1lpMUhodHFTWFA3WU5wOFBDN0hVK3lWRjNjRzBoYlhqQkZrdktq?= =?utf-8?B?U1dLQkhnUDB4Y2J3eCtwZmtYaHlFRjJHS2VOaFM0ajVHWjlwWE8xdUdaYUNi?= =?utf-8?B?emVSbFlDMEVHUjBMbFNHamhVWkpDakhRL2psMXR2SU54dW90aW5vWnBRK1pL?= =?utf-8?B?b0w2U0xkeVd6YmJvenE5UUE1SVBqYmJVaGxCWDJqSENkK0g1Y3hySjhoZitK?= =?utf-8?B?SjdHNnNGMk5uU1RZdW83ZjVJZ1hHSVdCQ0huMTB4MVBhN04vSnYwZ2tXaEtZ?= =?utf-8?B?QzdQakxvZllSNzFQa2lucUZ0QU9rZWlHYmFJSlB5UElnelhuZFdwWjRRMGZ4?= =?utf-8?B?c05NM3FCelpFblNXdndQcENSWWJodC9YSTlWVGFTam5sS1h2dUFpSGM0UXhr?= =?utf-8?B?d2NSbS9kTTl2REFqRHZQL3NBU3B2Y0JUN0tZWDB5OVpmZmc5c01meU4xRkdj?= =?utf-8?B?b0g2YjBhRmhNR01NeWFjcGlZMTA1UVZoVTR2aXBycnIvY3pDY2ZrM3hwalpp?= =?utf-8?B?SWVQVFB0d2xVWTlmdlJsQkxpTFVGSlc5TmJhejc3ZVRFTUFCZXN2QVBIdEpm?= =?utf-8?B?R08yay95b2xvZnpRVTdwVG1qYkFjVFVoeHJralZDTHFtcU1obGFrR2VlRVVn?= =?utf-8?B?cFd1YXExaXdtcUE0bGhDV3BCd0FBSVBMS0tXcWV5VDZpV0thaXFJNW54ZEV1?= =?utf-8?B?UFhIZ2ZhcUk0WjRtUlRCY0x2eGJRcWo5dkVkTGNUQVMyUFdsV2xlcHoxaWtk?= =?utf-8?B?OG1XNEhKZERsNFdXeUpKdm9tZFAxNUZJenB6NjVoWUJObjVxazlrTlNOaTQr?= =?utf-8?B?R1lwbUhLSnljbEkzYjcwMUF5Z2srS1Y4ZFEvcDBrOFgvVUNUM3pOM0I1cnV0?= =?utf-8?B?TUdBVDVkcDdKRDlxc29pSlA4bHBEQ3kwc1FDc2wxODdiYWU4cW1EZmdUVytT?= =?utf-8?B?Y0JyUFJmV0w4aDFrKzVZMXZLdGh3ZkMyMlV6RWJybytMNS9aUUVvTmduMnJo?= =?utf-8?B?R2orQlZEd0E4ay8vR2lUM0twaEt3SFYxUUFDaWEzLzBtSWxTSzZaS1pyemsy?= =?utf-8?Q?M+XR8ehq4rjqrFx5jk=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5546.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 52b884bb-ddf3-4e4b-36fe-08d9510d17e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 14:44:52.5685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 09uNm2UCrH8yzoXzL8g+XBopxic6OIeBs2Yp2Q2ZiZvFQXcE0UarHvJeJeEY4dWiEHLcEcns/HkXnJpnDf8tEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5029 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 14:45:00 -0000 RnJvbTogUmVzaGFkIFJhaG1hbiA8cmVzaGFkQHlhaG9vLmNvbT4KU2VudDogMjEgTWF5IDIwMjEg MDA6MDMKCjxJIHNob3VsZCBoYXZlIHNlbnQgdGhpcyBhIGZldyB3ZWVrcyBhZ28gd2hlbiBpdCBn b3QgZG9uZT4KCkZZSSwgTWFoZXNoIGRpZCB0aGUgZXh0cmFjdGlvbiBvZiB0aGUgbXBscy10ZSBm cm9tIGRyYWZ0LWlldGYtYmZkLXlhbmcgYW5kIGl0J3MgYmVlbiBzdWJtaXR0ZWQgdG8gdGhlIFJG QyBFZGl0b3IuCgo8dHA+ClR3byBtb250aHMgaGF2ZSBwYXNzZWQgYW5kIEkgc2VlIG5vIGNoYW5n ZSBpbiB0aGUgUkZDIEVkaXRvciBxdWV1ZS4gIFdoYXRldmVyIHdhcyBkb25lIHdvdWxkIGFwcGVh ciB0byBoYXZlIGJlZW4gbm90IGVub3VnaC4gIEkgd2FzIGV4cGVjdGluZyBhbiBhY3Rpb24gYnkg dGhlIEFEIHRvIGJlIHJlcXVpcmVkIGFuZCBoYXZlIHNlZW4gbm8gc2lnbiB0aGVyZW9mIHdoaWNo IG1heSBiZSByZWxldmFudC4KClRvbSBQZXRjaAoKUmVnYXJkcywKUmVzaGFkLgoK77u/T24gMjAy MS0wMy0yMiwgMzozMCBQTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIFlpbmd6aGVuIFF1IiA8cnRn LWJmZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB5aW5nemhlbi5pZXRmQGdtYWlsLmNv bT4gd3JvdGU6CgogICAgSGksCgogICAgSSBhbHNvIHN1cHBvcnQgdGhlIHNwbGl0IG9mIGlldGYt YmZkLW1wbHMtdGUgbW9kdWxlIGZyb20gdGhlIGJhc2UgQkZEIG1vZHVsZSwgc28gbW9kdWxlcyBs aWtlIGlldGYtb3NwZiBhbmQgaWV0Zi1pc2lzIGNhbiBwcm9ncmVzcy4KCiAgICBUaGFua3MsCiAg ICBZaW5nemhlbgoKICAgID4gT24gTWFyIDIyLCAyMDIxLCBhdCAyOjMzIEFNLCB0b20gcGV0Y2gg PGlldGZhQGJ0Y29ubmVjdC5jb20+IHdyb3RlOgogICAgPgogICAgPgogICAgPgogICAgPiBGcm9t OiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBSZXNoYWQg UmFobWFuIDxyZXNoYWQ9NDB5YWhvby5jb21AZG1hcmMuaWV0Zi5vcmc+CiAgICA+IFNlbnQ6IDE5 IE1hcmNoIDIwMjEgMTg6NTgKICAgID4gVG86IHJ0Zy1iZmRAaWV0Zi4gb3JnCiAgICA+IFN1Ympl Y3Q6IERyYWZ0IG1pbnV0ZXMgZm9yIEJGRCBAIElFVEYxMTAKICAgID4KICAgID4gQkZEIFdHLAog ICAgPgogICAgPiBEcmFmdCBtaW51dGVzIGhhdmUgYmVlbiBwb3N0ZWQgQCBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTExMC1iZmQvCiAgICA+CiAgICA+IFBsZWFzZSBw cm92aWRlIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IEFwcmlsIDJuZC4KICAgID4gPHRwPgogICAg PgogICAgPiBJIHN1cHBvcnQgQWNlZSdzIHN1Z2dlc3Rpb24gdGhhdCB0aGUgVEUgcGFydCBzaG91 bGQgYmUgc3BsaXQgZnJvbSB0aGUgQkZEIFlBTkcgZHJhZnQgc28gdGhhdCB0aGUgb3RoZXIgdGhy ZWUgV0csIHdobyBoYXZlIGJlZW4gaGVsZCB1cCBmb3IgeWVhcnMsIGNhbiBwcm9ncmVzcy4KICAg ID4KICAgID4gVG9tIFBldGNoCiAgICA+CiAgICA+IENvcHlpbmcgdGhlIExTUiBXRy4KICAgID4K ICAgID4KICAgID4gTWVldGluZyByZWNvcmRpbmcgaXMgQCBodHRwczovL3d3dy55b3V0dWJlLmNv bS93YXRjaD92PXZTcWZKSjNnT2MwCiAgICA+CiAgICA+IFJlZ2FyZHMsCiAgICA+IFJlc2hhZC4K ICAgID4KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KICAgID4gTHNyIG1haWxpbmcgbGlzdAogICAgPiBMc3JAaWV0Zi5vcmcKICAgID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3IKCgoK From nobody Tue Jul 27 07:57:30 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF803A083A for ; Tue, 27 Jul 2021 07:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDntdHFU9gfQ for ; Tue, 27 Jul 2021 07:57:24 -0700 (PDT) Received: from sonic309-13.consmr.mail.bf2.yahoo.com (sonic309-13.consmr.mail.bf2.yahoo.com [74.6.129.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92CB3A0965 for ; Tue, 27 Jul 2021 07:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627397815; bh=cDCBJTr1skjsGUymIWz7NcXARh3JmeQggnOScKph+Gw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=hXJg2jpk3QrM0ROkPsqUyDEBneKQE7ILuxt3v/8rtzxh3GFikah7KK87vlMckcP2H7+OuVicMCrx0jv/n51Y1HM9jq3AncDK2InNLyzTsbZ2uPLFjWj1k0y69u3/V1J9W6eUOqKsKA887f0eBkmcmiml00/e/Y4RKAHqGHruyUru356WDuWa7+JV4Afk3OjQWaxg7pep/yh+p3AE9AavCWjFWD3w5FFmOy/27V1dD93rW8bGZaHJiO0d4dfQ5y7JQT6oN0HmqvfN2tg4Gdd7ZNnIY6mZinOs5Sgyf4ohn5k1aSl0ubSEqhAvOksLiX8mpb6SxiqXETwK8R49OVjh+w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627397815; bh=Vx4Mm10NFG0a5Iukzykwgl+4KzNFYCiXaOsdKoIyDqS=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=NdTmyRr0KzDApKyhiP2PKlb40vnoAV3mvwMZcXW0KhO3WHM/b+A1acT7b12W6479X5Asgmk8OKNxpHdrHksS/X79zuw9uB0YceVu6HkQTmOfdtsWnmgwsPI3ttCDhyzrnRXowD+FLdg5XADLk0TGh2axNKMcTNMEe7BY9CYBsUABzMkfOg21awdZ9MdACiPjY+gwPTO7PjCeT1Zn2cwE8equA4nyu9qIlXT7s+ZHydtKdmoxNSUm0epL/1zA6nrNAK+otkb5/KkHeREkRc506hH3Z1dKzZ9/XdDfHjZJDHbgHtKaESUPkbN/DUY1ZnQEjBcTHw3WTN20tGTtCw+GXQ== X-YMail-OSG: jztEc1YVM1kzYEUfsvQptPTzVPzbTJi92Xa5OL_2OIE73ce4GF9ZCF0.C_sTEzn OMWiOp_LBgJ1viFCPbYWGTAYtJPgq6C5Hdpr3yY.v9JuZK82X.tqGy3QC01m3m9saUX6479THLxi rwouugN.hEC0R8lpC9mqvn7pxi9cWl5IQAWrRLpwlxl0d6n30MDKk6qsrEafChvjemZnsGAAEUqv KK7WdVTRKWTl_TJQPciKOZ03KdE2wgvVxZ4CiEDE3i495BVygqxzNqb0HK6iZ95YjwifqFfgH7.f 3SOdM3gezek.UoTsMYZ.PgfGT0RdFN5jUKACA7StTiH0XoRffFb5VTB7f.bHy8zq0R6u6m.XwgSz oB3GnpmLCmBpj9GY5RV5e6EmuyZ7DbLWRW8u3kS8h0eR9bkWH8mBPnMtkaxAmqg4GEO7tjef945w l0k78xMgl_yEgh.J.sSLRth2d7Sc9eN5ICeRpcaZ2vNX5rzqvBZF68dFZ1Lh_nM37hZuR1tMIToC Q.89HE.hb.sxZJK2ZJHFHh8_GZdkFlT8hYezfMj4QkT56sq29qnuRVV5.MKpk.WddZudBEZO1S7m NnPtPhJSS3YReVkpAYjtOZKYsNvEka9StvwhskVMchXvvRGoiZq1MjaPUPUFTCMqGMjwNGwri00g QgpHpCdZagnlnrWBgasoFv0wCSvJyo4arc0xLRILp9SqAt0YrvFymmEyNP4E61c.NtU5kiizyz3l hDI9skCb25sHRTfPXWaSSJUKh4myG7MmDSENX6dTNCzqlUPfHmGQaqv0U3qk80PT562CqU6ux3kk AE3EUUYFp54yjeALbMrV0.fzm.MpFnJj10Qp95zHMEMPVQmyAawpUUnBicQGXY1u.ahgpLnsEsXR MtZJE2UCVoj8CPLAmpn649K8TgEqKSIHzw2noROLptoFdGSe9YIgrGRQKwupP9VqqutaEqr6wAZB h9bxIXYJ4SUxOcDTesLrGJls.IUoaVlIjyA7R_sZYFfLFW9aLHzt76iffs1zsfQvTzcYAjvOTGJE 5Y6KlRq24hFX3YlN1Pd86ZG3yxz65FBypYmik6W_DdMcHPAzyFFQVqmrMwMp64It4lcO.7ab2t1S svSWw2arnrr5HKjMo9OISr_7kvo_VBW4BeGsMeYEyjm1_QHvbaMc08INTy6s9Fys7kGGu_sKhRUS xa7Oj5ZN.XFj3AkhVymzrCPFpKML_BtHKS8i95yhTviHdDSav.60VTlIoQmgLZfnjaEaah5EeBEi _Fv48tJ7XIDfcVSmz_060yxC1NOvdgNzATfTxbhDzGbjPUxHEYeQJWaQRiFao38p.vE3X5Y8q69I deDXeRx0wEtO1cC5bSxbT9vAjHmVDyw5JrItl1FOt3HZlInBMuskG0IjwEwVl8zvF4KPsgEdTaKu fhoQidOS6YDl6e9_01AtHnC.SZNqdzDwK_KUWli0N8QITF7SN7niYq5QCoCEziNMb_4jODZ9NDLb bGpB5uVo.799gBVF.OeNHPLuKmPNMZVz_Tmdt.YO4ybfz0T6ZsHkKhfInzm8pXsNwrVSPmZkdN9n N8QofgoqAWSVifEbkFLOnCpmTCI4uvT6n1FjxsKeFDtiB89p13tALclCgUawagUDBWUep80Q1kF_ szvWOb.crGUZ5SDR7Mt5xrYWn_dYHGswfl5VFeaBRAAICMfxbT1bpv3vOTLC5G0ouHHX7UxZBGMu REArU10DYNdsK8Hbi5SQh9UkAGDI0ZQ_J7OHuNIA_I5YpZDNsXZLnL7a7BKjfsVQCecf5ZWU4yKh wZaPBGLe6OYyT5QmBpykJfFq6mXrGsrzELcxxT_RqTTmeHssnyap0TMHvGImHQ4rBLlij7QdcKM9 VpDJsrDrutZwFOZh.iFFqxudRHDBFKK0XZp7eiRCu4b9ejZ5C0u799R0eHRt0L6fKonv2I0Cpyu8 NOTNxgMfwcEgYz.cqYcTmZkFeJNb_Qmpvue1jOj8y8vqxJFRsOfCl3Ko.d0rhFOlQ670CAU8vO90 18Ie2Cm4s5m9jnQobWJEKwmI6S.5.v3_A6bJYvnSSGzFpiv3jMEsFMLcJfRn671ifngzif90H8_9 fmYwnMtBq2HCcLdiDTYhqLbu7enDz7bu5qcUpDDfmvH1qQqqy09gQnL8YRRBFfM1O8i71OOwMrTh yyauSf_5GePqTrHK9uPStUXlfvOmCHqeCOKG_RFNOgVj7ni5EG2I_FYjZvasVC_sYKW65EXEy1Mc M5DkkSE4WHbVl3pj0GUmLXwUWv95Q_k3hlfdu_6SgocAgufPIq_5qonG_6kE.6.puC0bRsaGH_iH 2_PCKhOgQwXJqdkF_8MZXzg_olUdafFVp2JC6FkusPo4SW848k_vUb.fUFNqxTn7g.GSQ4RMtosw hRT__nqFGQmXrnx5hNzFTlYwqiFOPZny4nb65iR1cveFJrJG29_vAuyDYe2_KdH.nBjUGbW_g7pQ sSiDrQguE9Rtwz0S3MezJhYRWKqJTB9lOmUo5uLHConeO0KvHfjmfdae9xLGZMejLszHW8E7ozgN hhDBUIqgQti.8mzQ_NdRze5y7R8tr7TtgHpIvmpXs2dDd9ckEGauBR9P15QolmRPXwgWMBMhWS8J lf6pKSvPJE9X7lrwJAPPDCv1Qo5WUaPqVoiX6aO4tEuEYZhNuM87AYqbiCfl7jIRe6uD3 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 27 Jul 2021 14:56:55 +0000 Date: Tue, 27 Jul 2021 14:56:55 +0000 (UTC) From: Reshad Rahman Reply-To: Reshad Rahman To: Yingzhen Qu , tom petch , John Scudder Cc: "lsr@ietf.org" , "rtg-bfd@ietf. org" Message-ID: <781624976.145062.1627397815151@mail.yahoo.com> In-Reply-To: References: <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93.ref@yahoo.com> <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93@yahoo.com> <40AB32BD-3138-460F-B385-B8BA6D1EA8FB@gmail.com> Subject: Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_145061_2064489441.1627397815149" X-Mailer: WebService/1.1.18749 YMailNorrin Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 14:57:29 -0000 ------=_Part_145061_2064489441.1627397815149 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adding John (AD). On Tuesday, July 27, 2021, 10:45:07 a.m. EDT, tom petch wrote: =20 =20 From: Reshad Rahman Sent: 21 May 2021 00:03 FYI, Mahesh did the extraction of the mpls-te from draft-ietf-bfd-yang and = it's been submitted to the RFC Editor. Two months have passed and I see no change in the RFC Editor queue.=C2=A0 W= hatever was done would appear to have been not enough.=C2=A0 I was expectin= g an action by the AD to be required and have seen no sign thereof which ma= y be relevant. Tom Petch Regards, Reshad. =EF=BB=BFOn 2021-03-22, 3:30 PM, "Rtg-bfd on behalf of Yingzhen Qu" wrote: =C2=A0 =C2=A0 Hi, =C2=A0 =C2=A0 I also support the split of ietf-bfd-mpls-te module from the = base BFD module, so modules like ietf-ospf and ietf-isis can progress. =C2=A0 =C2=A0 Thanks, =C2=A0 =C2=A0 Yingzhen =C2=A0 =C2=A0 > On Mar 22, 2021, at 2:33 AM, tom petch wrote: =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > From: Rtg-bfd on behalf of Resha= d Rahman =C2=A0 =C2=A0 > Sent: 19 March 2021 18:58 =C2=A0 =C2=A0 > To: rtg-bfd@ietf. org =C2=A0 =C2=A0 > Subject: Draft minutes for BFD @ IETF110 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > BFD WG, =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Draft minutes have been posted @ https://datatracker.ietf.o= rg/doc/minutes-110-bfd/ =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Please provide comments to the list by April 2nd. =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > I support Acee's suggestion that the TE part should be spli= t from the BFD YANG draft so that the other three WG, who have been held up= for years, can progress. =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Tom Petch =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Copying the LSR WG. =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Meeting recording is @ https://www.youtube.com/watch?v=3DvS= qfJJ3gOc0 =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > Regards, =C2=A0 =C2=A0 > Reshad. =C2=A0 =C2=A0 > =C2=A0 =C2=A0 > _______________________________________________ =C2=A0 =C2=A0 > Lsr mailing list =C2=A0 =C2=A0 > Lsr@ietf.org =C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/lsr =20 ------=_Part_145061_2064489441.1627397815149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding John (AD).
<= div>
=20
=20
On Tuesday, July 27, 2021, 10:45:07 a.m. EDT, tom petch= <ietfa@btconnect.com> wrote:


From: Reshad Rahman <re= shad@yahoo.com>
Sent: 21 May 2021 00:03

<I should have sent this a few weeks ago wh= en it got done>

FYI, Mahesh did the= extraction of the mpls-te from draft-ietf-bfd-yang and it's been submitted= to the RFC Editor.

<tp>
Two months have passed and I see no change in the RFC Editor que= ue.  Whatever was done would appear to have been not enough.  I w= as expecting an action by the AD to be required and have seen no sign there= of which may be relevant.

Tom Petch

Regards,
Reshad.

=EF=BB=BFOn 2021-03-22, 3:30 PM, "Rtg-bfd on beha= lf of Yingzhen Qu" <rtg-bfd-bounces@ietf.org on b= ehalf of yingzhen.ietf@gmail.com> wrote:

    Hi,

    I also support the split of ietf-bfd-mpls-te module= from the base BFD module, so modules like ietf-ospf and ietf-isis can prog= ress.

    Thanks,
    Yingzhen

 = ;   > On Mar 22, 2021, at 2:33 AM, tom petch <ietf= a@btconnect.com> wrote:
    >
    >
    >
    > From: Rtg-bfd <rtg-bfd-b= ounces@ietf.org> on behalf of Reshad Rahman <reshad=3D40yahoo.com@dmarc.ietf.org>
  &nb= sp; > Sent: 19 March 2021 18:58
    > To:= rtg-bfd@ietf. org
    > Subject= : Draft minutes for BFD @ IETF110
    >
    > BFD WG,
    &g= t;
    > Draft minutes have been posted @ https://datatracker.ietf.org/doc/minutes= -110-bfd/
    >
 =   > Please provide comments to the list by April 2nd.
    > <tp>
    >    > I support Acee's suggestion that the TE = part should be split from the BFD YANG draft so that the other three WG, wh= o have been held up for years, can progress.
   = ; >
    > Tom Petch
&nb= sp;   >
    > Copying the LSR WG.    >
    >
    > Meeting recording is @ https://www.youtube.com/watch?v=3DvSqfJJ3gOc0
    >
    > Regards,<= br clear=3D"none">    > Reshad.
   = ; >
    > _______________________________= ________________
    > Lsr mailing list
    > Lsr@ietf.org
=     > https://www.ietf.org/mailma= n/listinfo/lsr


=
------=_Part_145061_2064489441.1627397815149-- From nobody Tue Jul 27 11:49:31 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482433A0A8D; Tue, 27 Jul 2021 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=F/Vjr3np; dkim=pass (1024-bit key) header.d=juniper.net header.b=Td6mGPK7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbP4rHuQOemK; Tue, 27 Jul 2021 11:49:19 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F08D3A0A88; Tue, 27 Jul 2021 11:49:19 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16RIP9rY005666; Tue, 27 Jul 2021 11:49:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=BKyHyV9NkZOsk9KelxloOGzRwrT6acm9rjFT6TfBMoE=; b=F/Vjr3npgSajSfEqj6u2+oAHi1fze+V4Ool49DDibKJLSWvtiMh2sQu7MeHApk5r3jmU MutbX7+DbuPYXwkSAmPnX/0ihmo5s0yWIvCd3BD2cZ9lvsml2LBGa2IgWupGu9AdMUpy MtYQfwvPzs5J7uzQXXDbtQVyqysS5Fha7ULD1ACbd8PC6fqCqzyDrI8Q9EtYkxGzorSw gdIfWBp+ilwU38K/Jjkh8vAeF3ic5n0liHIRZzuR2z+x6g5Y/7OGw7AZ0gWddxwV1IyK /b5urDvIyXGsS+jNxTsTAQr1qV2BkMir+wV8GQn4KWqTEVLBa9/2XotP6SVozSrDO+jL NQ== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2107.outbound.protection.outlook.com [104.47.58.107]) by mx0a-00273201.pphosted.com with ESMTP id 3a2q2f82g8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 11:49:14 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P1KZI0m4e4ayTf8gX5TuO7cc1QPOWcfE5Bwd9sT0c3EL5j8DTud5uPpWt4pfnBzCj7ybb0A2/eXQOGfvIB67PMiWeNSKXMsk4z1rOEE2qCvSwDsOx3/p3C5rhAgZea+/H1K5WdK5zOj2+WOK59xR0gM+cmgVRw19z6ZWK1MgFE2u0+kBU5TWTtImzq3px9TDOJRDwXG37XSFzG9Epobnf7wx6s5XcD/tVHIs+Az0rzlz35y6yptSD9NfM8aM/gUAgQhAiNaOfbj2/8VHUhxZaZmFgPGtn5T2PgflPp2uKIInRrDzlJzrwDvLhoeCsyNSpwqse9NEm6s8SDEAmvxkiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BKyHyV9NkZOsk9KelxloOGzRwrT6acm9rjFT6TfBMoE=; b=UqvjtnfRG/bNphA0sFxjmFR3/z4Qt6pdRHvxuxxQFuedgMnuE48xln/t4PD5PNIVZCMXCVEw49hHA+cax6hI8kplBDbcYjd2DdzbkKZfzaLz0pDx6Anrm0st3czDFKrea8/kF7hQa89jnAGXjWvCjoMYyE2g54SHOHAjorTD/D51C3o6YQzVZ/ffuJYDXh7SKl7NKp44nY9EiEKRcQz8/jluJ0kORnXVKsselaK4paAIXl+8ycdja2mBI2vukGLPNIK3WtQfmHRLgRB+IvjZJFn/ETcq187dpS/c+81vwq6ymA5u+x5HaTp1ZRHy0jq8w+aI2PbCOh14pMgocOcxfg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BKyHyV9NkZOsk9KelxloOGzRwrT6acm9rjFT6TfBMoE=; b=Td6mGPK76387vBfe37woEeP7oA8vXSo1DDqoWQ/FbQWgH55+exR3Yz2dAVqqZukXuDy1QIMYvLRKXwu8jzjzaG2GvtuVvDWxJC5e9RqFGmCf6OI4HMYrqNcw2P2W0/zbrlRwmwKvozggu7WovXP0pb8TyuVIqoHstpdIP2moqug= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6205.namprd05.prod.outlook.com (2603:10b6:208:d1::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.12; Tue, 27 Jul 2021 18:49:11 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c%7]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 18:49:11 +0000 From: John Scudder To: Reshad Rahman CC: Yingzhen Qu , tom petch , "lsr@ietf.org" , "rtg-bfd@ietf. org" Subject: Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Topic: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Index: AQHXHPHlY/eJmrY4iU6TuKlPHzUxeKqPww8AgACmZgCAXPVdgIBqUzQAgAADXoCAAEDjAA== Date: Tue, 27 Jul 2021 18:49:11 +0000 Message-ID: <4478FB07-361E-4152-89E5-4E0193CF1BE1@juniper.net> References: <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93.ref@yahoo.com> <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93@yahoo.com> <40AB32BD-3138-460F-B385-B8BA6D1EA8FB@gmail.com> <781624976.145062.1627397815151@mail.yahoo.com> In-Reply-To: <781624976.145062.1627397815151@mail.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.100.0.2.22) authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5410324b-83bd-4e1b-2031-08d9512f3944 x-ms-traffictypediagnostic: MN2PR05MB6205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MZV1KNrmKDe0hqiTGVOrQdc5URFAaMMGWFV7RZPQvNKhA85ML4sWBszh90BRjBhoLAmARfrwyu9PaURiq15vctHgwIPIuAVDqCUD9ZrMDS9D2qnglRXUithsuVrQQK3gk1TVrU3Ta323i+s0Cd3nVrmAP8IuIgeunDCjwB6RXtlJFYnnJyOzyQeLyeU4qDrIq4pJEn+XsDq0itHa9/UKuwVCkQT1gA+OQz/iWGrj4SBmzOClfPXnTkftjFhhApIcae5PSJjMTdLtPo0GhfT/oKuEaF2F9CD5P/aommq15HBkSJulYV6IMzkH9M5SS87zy0WcfSeR1VPGLtH+6Y53Ov3mS4EEWenNtXvMpG6ifOE048Wg4izJJ4iDquyytSJHzn3SomSBfbY2tgL4l7zEgtwqK/WeHbE8lwUnpcP9mPvM/JYh6vBHs/8rhFCJkvaUB0MPWzRp5Jl8n4kkhIxi/pvxSmREDQHkEc29T+px8VilGXDA9h0BN/MBGH5GbAOMvpp8ORKN2U0kZBhzeMLwLfPW/kp4RZ+1oDIlBQNNHyKWfu91BNSD7iDSVEn3lru64+Di15GnV5PaCjHfMTDzcNtZfppSQinhhySNN44KniqM0smqkFpqVWVlLlWlLWTJT84n/8iUeaR3BaQX/zxOqw1cPfkHQ1c8UZS1kDV0W1vvRmGvnUbLDk+8bQFoscFrOoflvUeUKx56VRiZygWsbMpXfEW0mBXWP7p1KJoZOsHkBBDzMELkOebnxpwVNjmi2jXFy+wk0CYJ8DiGZbrHEyLGvmNryGKECMO2KHjgJtPRKVJqpYvA1Sy4678FEc0r3R+i3hfcyNavuyZGL7BeV2useM0wruEWNlnNahygYj0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(186003)(966005)(33656002)(2616005)(8936002)(71200400001)(6486002)(8676002)(5660300002)(26005)(16799955002)(4326008)(122000001)(38100700002)(6916009)(53546011)(86362001)(6506007)(66946007)(83380400001)(166002)(316002)(36756003)(66446008)(508600001)(64756008)(66476007)(76116006)(66556008)(91956017)(6512007)(54906003)(45980500001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aVRQbGFGcU50emgyeHhaM3hrMFE5SVk4ZGxwdG11V3BBZ0NhLzM1enhRM2p2?= =?utf-8?B?STZhV1ZSTVd4UUtZcTFRaEt2dWw3YjFiZkxWcVZBdEFuNk5PUVBEWUY3OEdQ?= =?utf-8?B?UUtEUjB0TlRPN1JZYVJJaDRhS2I3akV0Rlk3ejVpdXNjQU1FaGxmMVE1WmFI?= =?utf-8?B?V25LTG4yVFgxMDB0c3ZjUGkvZWx3VHhNcU40Y1hSWExhSCtVV0hnbGtlUHhn?= =?utf-8?B?cmVrODVmMUJIeC9EanZMK1loMzVWb1Y5dDQ2UlhlV2hWMHFVUzNMcGRzeVNH?= =?utf-8?B?YnpnVkhpV0txeWlTbXVuWTJLRzBpYXFndStuVlg5dkxPaFA0eGkwMTVZTXlE?= =?utf-8?B?NUh6b3JRcXRvamlsa25jQnN6bVp5cWZ3ck5VUC8xd2hteWd4eXZiM3AvejRZ?= =?utf-8?B?aU9xWmhiRm1XM3BnWWlrS1lDRkFDWnFuM3Myc0cyZWRmY2hTSis4R2RXSGVt?= =?utf-8?B?M2d4MDNTWjRKTjJrZWYyems4ajE1L0ZSeVJ4WTIyVHlJcWxIRkdUclR6ODFa?= =?utf-8?B?S3RVaXVCZGxLSFNsOEp1dW4rbWNFUDdORkZTcXFLZUlJR05IQ29qYlRTcGI5?= =?utf-8?B?RXB2WHpMakp4MFBBclpEZVVJakg5VVpXOEpmMjZFa053OGt5U0NPcDlYNVlq?= =?utf-8?B?MkxaTGd5R0ZlcUx3VU5EZXhxNlV0SnNZMjlQWDBmTTJFQzlCUFhnR1lhT2Zn?= =?utf-8?B?RStSc2NIMldpUGNPaDlid1d1K2xYZUdRWG9aZU5xTXJGOFY1T0crdXdFZ0dM?= =?utf-8?B?UmxORmwvSld3VnNSVVhUeXdiUkZyUGV5b0F4WjZ2NXh2RTgxT25WRm1sbEd4?= =?utf-8?B?MTJLK3ZwZ2RQeDNiYmVmdHFaTjNlZnVMZm9ibEIvWmo5dGxNeG1Manl2dFNO?= =?utf-8?B?OW83enpXUVovRFQ0UU1lWkJpYlZObUx0N3paOWJqM08xQWFSOXV5eTNLZVB5?= =?utf-8?B?c3QwZ1JheHBjZnZSTFM0UWJ2VklMS3pIeCt5Ni9BeTVvQWpYU2JLVmhLeFRl?= =?utf-8?B?UHBveHV5dGx5OG9sRFFNMUVmVm1PM2gvT3p4c2lKeW9BNWovUW81djhDSUJH?= =?utf-8?B?OHhZeFlwLzZDUDRlbXNlZWt0a0wxNE5BOUNmU1RzT2ZJdDk3RHRNc2hpRVAr?= =?utf-8?B?MitYZEdTYUdhbVQ3K0cxWHp6Q2NHUks1QUJuWHM0SDlsK2wwbk0wb2RiZW1i?= =?utf-8?B?UjRlemhnMFhWUGI0T25EcUZER0xTWTdOZFB4RzNxTkJCQ3lCVWRmWVVYZWI1?= =?utf-8?B?ZDQ1Y3EyTUJDOXNPTGcvTWpodWFNazNwdDlTWlhBSHg0ODRwazlBU1dDdFVu?= =?utf-8?B?d001TlE2VnBadWtrcEhjT0tLWTNtemkzemVNYXlyc1k4T0pLaGhQSnEwMGlB?= =?utf-8?B?cEQ5UEtRNmF6S2ZPaVAyQVQrazRhcjkya3I5VUZEQVZSU0Q3Rk9RUktOR3Jy?= =?utf-8?B?S0lYWUp6ZFlhTHlNamtXYTNWdFhUL1NYTTBLNUdZY3RGbmtML0VpcWxuRTZE?= =?utf-8?B?ODV0Y0t1Q2tyWXBnS29BbU5ReWRCMUZxQlFmK0tMUzBsTGN5WFdOQzIwS00y?= =?utf-8?B?b20xd20vSTNob2hRcWwrZUZPSmszSjJER3MrTVBJTVo0eWs0eCtmMGhDaW96?= =?utf-8?B?V0VPUXFmVklEUW4zNW5RWXJ4d01ZdmF0TXY3R3Npa09wbnFwdkZJaU96c2NC?= =?utf-8?B?bVozaVc4bHVkWDZqcVd4MHZDaHBkUE40Y0pBTTZqWGxoRmdSelRmUHNDbk5q?= =?utf-8?Q?S7qaI4Uhk34v2B64Rgdj1E7AlewhFnnj17opShm?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4478FB07361E415289E54E0193CF1BE1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5410324b-83bd-4e1b-2031-08d9512f3944 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 18:49:11.3685 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MAx4wejFhAniRpicXC4lNzN5q222+sXV3uLC6QB6u+XTSm5hddFa5lzUfiCYMijJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6205 X-Proofpoint-GUID: x81Hh_EN-WUqQ1PsN6mycdW9fDpgmWEF X-Proofpoint-ORIG-GUID: x81Hh_EN-WUqQ1PsN6mycdW9fDpgmWEF X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-27_10:2021-07-27, 2021-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 suspectscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 impostorscore=0 clxscore=1011 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107270108 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 18:49:26 -0000 --_000_4478FB07361E415289E54E0193CF1BE1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkZDIEVkaXRvciBzdGF0ZSBpcyBNSVNTUkVGLCBhcyBwYXJ0IG9mIGNsdXN0ZXIgQzMzNjogaHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzMzNi4gSWYgSeKA mW0gdW50YW5nbGluZyB0aGUgaW5mb3JtYXRpb24gdGhlcmUgY29ycmVjdGx5LCBJIHRoaW5rIGl0 4oCZcyBibG9ja2VkIG9uIChhdCBsZWFzdCkgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUuDQoNCldh cyB0aGUgc3VyZ2VyeSB0aGF0IFRvbSBtZW50aW9ucywgZXhwZWN0ZWQgdG8gY2xlYXIgaXQgb3V0 IG9mIE1JU1NSRUY/IElmIHNvLCBwbGVhc2UgZ2l2ZSBtZSBzb21lIG1vcmUgZGV0YWlscyAoZWl0 aGVyIGluIHRoaXMgdGhyZWFkIG9yIG9mZmxpbmUpIGFuZCBJIGNhbiBjaGVjayBpbiB3aXRoIHRo ZSBSRkMgRWRpdG9yLg0KDQpUaGFua3MsDQoNCuKAlEpvaG4NCg0KT24gSnVsIDI3LCAyMDIxLCBh dCAxMDo1NiBBTSwgUmVzaGFkIFJhaG1hbiA8cmVzaGFkQHlhaG9vLmNvbTxtYWlsdG86cmVzaGFk QHlhaG9vLmNvbT4+IHdyb3RlOg0KDQoNCkFkZGluZyBKb2huIChBRCkuDQoNCk9uIFR1ZXNkYXks IEp1bHkgMjcsIDIwMjEsIDEwOjQ1OjA3IGEubS4gRURULCB0b20gcGV0Y2ggPGlldGZhQGJ0Y29u bmVjdC5jb208bWFpbHRvOmlldGZhQGJ0Y29ubmVjdC5jb20+PiB3cm90ZToNCg0KDQpGcm9tOiBS ZXNoYWQgUmFobWFuIDxyZXNoYWRAeWFob28uY29tPG1haWx0bzpyZXNoYWRAeWFob28uY29tPj4N ClNlbnQ6IDIxIE1heSAyMDIxIDAwOjAzDQoNCjxJIHNob3VsZCBoYXZlIHNlbnQgdGhpcyBhIGZl dyB3ZWVrcyBhZ28gd2hlbiBpdCBnb3QgZG9uZT4NCg0KRllJLCBNYWhlc2ggZGlkIHRoZSBleHRy YWN0aW9uIG9mIHRoZSBtcGxzLXRlIGZyb20gZHJhZnQtaWV0Zi1iZmQteWFuZyBhbmQgaXQncyBi ZWVuIHN1Ym1pdHRlZCB0byB0aGUgUkZDIEVkaXRvci4NCg0KPHRwPg0KVHdvIG1vbnRocyBoYXZl IHBhc3NlZCBhbmQgSSBzZWUgbm8gY2hhbmdlIGluIHRoZSBSRkMgRWRpdG9yIHF1ZXVlLiAgV2hh dGV2ZXIgd2FzIGRvbmUgd291bGQgYXBwZWFyIHRvIGhhdmUgYmVlbiBub3QgZW5vdWdoLiAgSSB3 YXMgZXhwZWN0aW5nIGFuIGFjdGlvbiBieSB0aGUgQUQgdG8gYmUgcmVxdWlyZWQgYW5kIGhhdmUg c2VlbiBubyBzaWduIHRoZXJlb2Ygd2hpY2ggbWF5IGJlIHJlbGV2YW50Lg0KDQpUb20gUGV0Y2gN Cg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQrvu79PbiAyMDIxLTAzLTIyLCAzOjMwIFBNLCAiUnRn LWJmZCBvbiBiZWhhbGYgb2YgWWluZ3poZW4gUXUiIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHlpbmd6aGVuLmll dGZAZ21haWwuY29tPG1haWx0bzp5aW5nemhlbi5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQog ICAgSGksDQoNCiAgICBJIGFsc28gc3VwcG9ydCB0aGUgc3BsaXQgb2YgaWV0Zi1iZmQtbXBscy10 ZSBtb2R1bGUgZnJvbSB0aGUgYmFzZSBCRkQgbW9kdWxlLCBzbyBtb2R1bGVzIGxpa2UgaWV0Zi1v c3BmIGFuZCBpZXRmLWlzaXMgY2FuIHByb2dyZXNzLg0KDQogICAgVGhhbmtzLA0KICAgIFlpbmd6 aGVuDQoNCiAgICA+IE9uIE1hciAyMiwgMjAyMSwgYXQgMjozMyBBTSwgdG9tIHBldGNoIDxpZXRm YUBidGNvbm5lY3QuY29tPG1haWx0bzppZXRmYUBidGNvbm5lY3QuY29tPj4gd3JvdGU6DQogICAg Pg0KICAgID4NCiAgICA+DQogICAgPiBGcm9tOiBSdGctYmZkIDxydGctYmZkLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSZXNo YWQgUmFobWFuIDxyZXNoYWQ9NDB5YWhvby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQweWFo b28uY29tQGRtYXJjLmlldGYub3JnPj4NCiAgICA+IFNlbnQ6IDE5IE1hcmNoIDIwMjEgMTg6NTgN CiAgICA+IFRvOiBydGctYmZkQGlldGYuPG1haWx0bzpydGctYmZkQGlldGYuPiBvcmcNCiAgICA+ IFN1YmplY3Q6IERyYWZ0IG1pbnV0ZXMgZm9yIEJGRCBAIElFVEYxMTANCiAgICA+DQogICAgPiBC RkQgV0csDQogICAgPg0KICAgID4gRHJhZnQgbWludXRlcyBoYXZlIGJlZW4gcG9zdGVkIEAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMTAtYmZkLzxodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRl cy0xMTAtYmZkL19fOyEhTkV0NnlNYU8tZ2shVEc0eF9zc01hUWxNRGRWdTNCckJ5d0oxZW5XMHFq c0xTZy0wZjlDS2tlY1NWUEVBZmNmWHVDd3IwOG1MVXckPg0KICAgID4NCiAgICA+IFBsZWFzZSBw cm92aWRlIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IEFwcmlsIDJuZC4NCiAgICA+IDx0cD4NCiAg ICA+DQogICAgPiBJIHN1cHBvcnQgQWNlZSdzIHN1Z2dlc3Rpb24gdGhhdCB0aGUgVEUgcGFydCBz aG91bGQgYmUgc3BsaXQgZnJvbSB0aGUgQkZEIFlBTkcgZHJhZnQgc28gdGhhdCB0aGUgb3RoZXIg dGhyZWUgV0csIHdobyBoYXZlIGJlZW4gaGVsZCB1cCBmb3IgeWVhcnMsIGNhbiBwcm9ncmVzcy4N CiAgICA+DQogICAgPiBUb20gUGV0Y2gNCiAgICA+DQogICAgPiBDb3B5aW5nIHRoZSBMU1IgV0cu DQogICAgPg0KICAgID4NCiAgICA+IE1lZXRpbmcgcmVjb3JkaW5nIGlzIEAgaHR0cHM6Ly93d3cu eW91dHViZS5jb20vd2F0Y2g/dj12U3FmSkozZ09jMDxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj12U3FmSkozZ09jMF9fOyEhTkV0NnlN YU8tZ2shVEc0eF9zc01hUWxNRGRWdTNCckJ5d0oxZW5XMHFqc0xTZy0wZjlDS2tlY1NWUEVBZmNm WHVDempYNGNrNUEkPg0KICAgID4NCiAgICA+IFJlZ2FyZHMsDQogICAgPiBSZXNoYWQuDQogICAg Pg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+IExzciBtYWlsaW5nIGxpc3QNCiAgICA+IExzckBpZXRmLm9yZzxtYWlsdG86THNyQGll dGYub3JnPg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8 aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbHNyX187ISFORXQ2eU1hTy1nayFURzR4X3NzTWFRbE1EZFZ1M0JyQnl3SjFlblcw cWpzTFNnLTBmOUNLa2VjU1ZQRUFmY2ZYdUN3djlEWm9yZyQ+DQoNCg== --_000_4478FB07361E415289E54E0193CF1BE1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <1017D68F80811D4A9279A9E9567E4E98@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClJGQyBFZGl0b3Igc3RhdGUgaXMgTUlTU1JFRiwg YXMgcGFydCBvZiBjbHVzdGVyIEMzMzY6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzMzNiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzMzNjwvYT4uIElmIEnigJltIHVu dGFuZ2xpbmcgdGhlIGluZm9ybWF0aW9uIHRoZXJlIGNvcnJlY3RseSwgSSB0aGluayBpdOKAmXMg YmxvY2tlZCBvbg0KIChhdCBsZWFzdCkgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUuJm5ic3A7DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XYXMgdGhl IHN1cmdlcnkgdGhhdCBUb20gbWVudGlvbnMsIGV4cGVjdGVkIHRvIGNsZWFyIGl0IG91dCBvZiBN SVNTUkVGPyBJZiBzbywgcGxlYXNlIGdpdmUgbWUgc29tZSBtb3JlIGRldGFpbHMgKGVpdGhlciBp biB0aGlzIHRocmVhZCBvciBvZmZsaW5lKSBhbmQgSSBjYW4gY2hlY2sgaW4gd2l0aCB0aGUgUkZD IEVkaXRvci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpvaG48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBK dWwgMjcsIDIwMjEsIGF0IDEwOjU2IEFNLCBSZXNoYWQgUmFobWFuICZsdDs8YSBocmVmPSJtYWls dG86cmVzaGFkQHlhaG9vLmNvbSIgY2xhc3M9IiI+cmVzaGFkQHlhaG9vLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJ5ZHA0OGFkYTdieWFob28tc3R5 bGUtd3JhcCIgc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtjb3VyaWVyIG5ldyZxdW90OywgY291 cmllciwgbW9uYWNvLCBtb25vc3BhY2UsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsiPg0K PGRpdiBjbGFzcz0iIj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGRhdGEtc2V0ZGlyPSJmYWxzZSIg Y2xhc3M9IiI+QWRkaW5nIEpvaG4gKEFEKS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9InlkcDRhODY2YzVk eWFob29fcXVvdGVkXzgzOTE0OTg0NTEiIGNsYXNzPSJ5ZHA0YTg2NmM1ZHlhaG9vX3F1b3RlZCI+ DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssIEhl bHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTNweDsgY29sb3I6IHJnYigz OCwgNDAsIDQyKTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBUdWVzZGF5LCBKdWx5IDI3 LCAyMDIxLCAxMDo0NTowNyBhLm0uIEVEVCwgdG9tIHBldGNoICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZmFAYnRjb25uZWN0LmNvbSIgY2xhc3M9IiI+aWV0ZmFAYnRjb25uZWN0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9 Imx0ciIgY2xhc3M9IiI+RnJvbTogUmVzaGFkIFJhaG1hbiAmbHQ7PGEgc2hhcGU9InJlY3QiIGhy ZWY9Im1haWx0bzpyZXNoYWRAeWFob28uY29tIiByZWw9Im5vZm9sbG93IiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+cmVzaGFkQHlhaG9vLmNvbTwvYT4mZ3Q7PGJyIGNsZWFyPSJub25lIiBjbGFz cz0iIj4NClNlbnQ6IDIxIE1heSAyMDIxIDAwOjAzPGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4N CjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombHQ7SSBzaG91bGQgaGF2ZSBzZW50IHRoaXMg YSBmZXcgd2Vla3MgYWdvIHdoZW4gaXQgZ290IGRvbmUmZ3Q7PGJyIGNsZWFyPSJub25lIiBjbGFz cz0iIj4NCjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQpGWUksIE1haGVzaCBkaWQgdGhlIGV4 dHJhY3Rpb24gb2YgdGhlIG1wbHMtdGUgZnJvbSBkcmFmdC1pZXRmLWJmZC15YW5nIGFuZCBpdCdz IGJlZW4gc3VibWl0dGVkIHRvIHRoZSBSRkMgRWRpdG9yLjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9 IiI+DQo8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJmx0O3RwJmd0OzxiciBjbGVhcj0ibm9u ZSIgY2xhc3M9IiI+DQpUd28gbW9udGhzIGhhdmUgcGFzc2VkIGFuZCBJIHNlZSBubyBjaGFuZ2Ug aW4gdGhlIFJGQyBFZGl0b3IgcXVldWUuJm5ic3A7IFdoYXRldmVyIHdhcyBkb25lIHdvdWxkIGFw cGVhciB0byBoYXZlIGJlZW4gbm90IGVub3VnaC4mbmJzcDsgSSB3YXMgZXhwZWN0aW5nIGFuIGFj dGlvbiBieSB0aGUgQUQgdG8gYmUgcmVxdWlyZWQgYW5kIGhhdmUgc2VlbiBubyBzaWduIHRoZXJl b2Ygd2hpY2ggbWF5IGJlIHJlbGV2YW50LjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQo8YnIg Y2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KVG9tIFBldGNoDQo8ZGl2IGNsYXNzPSJ5ZHA0YTg2NmM1 ZHlxdDI2MDEzMTExMjQiIGlkPSJ5ZHA0YTg2NmM1ZHlxdGZkMDY1NDciPjxiciBjbGVhcj0ibm9u ZSIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KUmVnYXJkcyw8YnIgY2xl YXI9Im5vbmUiIGNsYXNzPSIiPg0KUmVzaGFkLjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQo8 YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0K77u/T24gMjAyMS0wMy0yMiwgMzozMCBQTSwgJnF1 b3Q7UnRnLWJmZCBvbiBiZWhhbGYgb2YgWWluZ3poZW4gUXUmcXVvdDsgJmx0OzxhIHNoYXBlPSJy ZWN0IiBocmVmPSJtYWlsdG86cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnIiByZWw9Im5vZm9sbG93 IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+cnRnLWJmZC1ib3VuY2VzQGlldGYub3JnPC9hPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vbiBiZWhhbGYg b2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgc2hh cGU9InJlY3QiIGhyZWY9Im1haWx0bzp5aW5nemhlbi5pZXRmQGdtYWlsLmNvbSIgcmVsPSJub2Zv bGxvdyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnlpbmd6aGVuLmlldGZAZ21haWwuY29tPC9h PiZndDsNCiB3cm90ZTo8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KPGJyIGNsZWFyPSJub25l IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgSGksPGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4N CjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7IEkgYWxzbyBzdXBwb3J0 IHRoZSBzcGxpdCBvZiBpZXRmLWJmZC1tcGxzLXRlIG1vZHVsZSBmcm9tIHRoZSBiYXNlIEJGRCBt b2R1bGUsIHNvIG1vZHVsZXMgbGlrZSBpZXRmLW9zcGYgYW5kIGlldGYtaXNpcyBjYW4gcHJvZ3Jl c3MuPGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4NCjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7IFRoYW5rcyw8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwOyBZaW5nemhlbjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQo8YnIgY2xlYXI9Im5v bmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIE1hciAyMiwgMjAyMSwgYXQgMjoz MyBBTSwgdG9tIHBldGNoICZsdDs8YSBzaGFwZT0icmVjdCIgaHJlZj0ibWFpbHRvOmlldGZhQGJ0 Y29ubmVjdC5jb20iIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5pZXRm YUBidGNvbm5lY3QuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJmd0OzxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7ICZndDs8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJy IGNsZWFyPSJub25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBGcm9tOiBSdGctYmZk ICZsdDs8YSBzaGFwZT0icmVjdCIgaHJlZj0ibWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9y ZyIgcmVsPSJub2ZvbGxvdyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnJ0Zy1iZmQtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBSZXNoYWQgUmFobWFuICZsdDtyZXNoYWQ9 PGEgc2hhcGU9InJlY3QiIGhyZWY9Im1haWx0bzo0MHlhaG9vLmNvbUBkbWFyYy5pZXRmLm9yZyIg cmVsPSJub2ZvbGxvdyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPjQweWFob28uY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDs8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IFNlbnQ6IDE5IE1hcmNoIDIwMjEgMTg6NTg8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIi Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFRvOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBzaGFwZT0icmVjdCIgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0 Zi4iIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ydGctYmZkQGlldGYu PC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5vcmc8 YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFN1YmplY3Q6IERy YWZ0IG1pbnV0ZXMgZm9yIEJGRCBAIElFVEYxMTA8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7PGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJmd0OyBCRkQgV0csPGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsg Jmd0OzxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDsgRHJhZnQg bWludXRlcyBoYXZlIGJlZW4gcG9zdGVkIEA8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgc2hhcGU9InJlY3QiIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTExMC1i ZmQvX187ISFORXQ2eU1hTy1nayFURzR4X3NzTWFRbE1EZFZ1M0JyQnl3SjFlblcwcWpzTFNnLTBm OUNLa2VjU1ZQRUFmY2ZYdUN3cjA4bUxVdyQiIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0iX2JsYW5r IiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTExMC1i ZmQvPC9hPjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDs8YnIg Y2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFBsZWFzZSBwcm92aWRl IGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IEFwcmlsIDJuZC48YnIgY2xlYXI9Im5vbmUiIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICZsdDt0cCZndDs8YnIgY2xlYXI9Im5vbmUiIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyIGNsZWFyPSJub25lIiBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJmd0OyBJIHN1cHBvcnQgQWNlZSdzIHN1Z2dlc3Rpb24gdGhhdCB0aGUgVEUgcGFy dCBzaG91bGQgYmUgc3BsaXQgZnJvbSB0aGUgQkZEIFlBTkcgZHJhZnQgc28gdGhhdCB0aGUgb3Ro ZXIgdGhyZWUgV0csIHdobyBoYXZlIGJlZW4gaGVsZCB1cCBmb3IgeWVhcnMsIGNhbiBwcm9ncmVz cy48YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyIGNsZWFy PSJub25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUb20gUGV0Y2g8YnIgY2xlYXI9 Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7PGJyIGNsZWFyPSJub25lIiBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBDb3B5aW5nIHRoZSBMU1IgV0cuPGJyIGNsZWFyPSJu b25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OzxiciBjbGVhcj0ibm9uZSIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZndDs8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IE1lZXRpbmcgcmVjb3JkaW5nIGlzIEA8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgc2hhcGU9InJlY3QiIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PXZTcWZK SjNnT2MwX187ISFORXQ2eU1hTy1nayFURzR4X3NzTWFRbE1EZFZ1M0JyQnl3SjFlblcwcWpzTFNn LTBmOUNLa2VjU1ZQRUFmY2ZYdUN6alg0Y2s1QSQiIHJlbD0ibm9mb2xsb3ciIHRhcmdldD0iX2Js YW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PXZTcWZKSjNnT2Mw PC9hPjxiciBjbGVhcj0ibm9uZSIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDs8YnIgY2xl YXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IFJlZ2FyZHMsPGJyIGNsZWFy PSJub25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBSZXNoYWQuPGJyIGNsZWFyPSJu b25lIiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJmd0OzxiciBjbGVhcj0ibm9uZSIgY2xhc3M9 IiI+DQombmJzcDsgJm5ic3A7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm Z3Q7IExzciBtYWlsaW5nIGxpc3Q8YnIgY2xlYXI9Im5vbmUiIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIHNoYXBlPSJyZWN0IiBocmVmPSJtYWlsdG86THNyQGlldGYub3JnIiByZWw9Im5vZm9sbG93 IiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+THNyQGlldGYub3JnPC9hPjxiciBjbGVhcj0ibm9u ZSIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgc2hhcGU9InJlY3QiIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xz cl9fOyEhTkV0NnlNYU8tZ2shVEc0eF9zc01hUWxNRGRWdTNCckJ5d0oxZW5XMHFqc0xTZy0wZjlD S2tlY1NWUEVBZmNmWHVDd3Y5RFpvcmckIiByZWw9Im5vZm9sbG93IiB0YXJnZXQ9Il9ibGFuayIg Y2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4478FB07361E415289E54E0193CF1BE1junipernet_-- From nobody Tue Jul 27 13:09:38 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5C93A0FCC; Tue, 27 Jul 2021 12:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuN59HP5b2M7; Tue, 27 Jul 2021 12:52:01 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B503A0FC3; Tue, 27 Jul 2021 12:52:01 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id ds11-20020a17090b08cbb0290172f971883bso6376947pjb.1; Tue, 27 Jul 2021 12:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xcNa/aryHKItA1tZHsSCu27PR5yJtirN4RwdKrDJhk0=; b=kTuBFmYRIYw9gI//3Nco5Hk3JPy8wMQqOABrGP+84UNA7H0yZB63XSh6I+NUhnuE79 rlmf7lpmFe2Izb9hrcmJcGDhiV1hdYtwFY8f9SX/bVr0d8Tl/ci5JryyWk6ABj3GJZRE iLNSienYW6Iqd/N4Je8UDTwFO01Zyzv5Y9dT2WdQg5VxWjf9aK5hTqRfjOgjGxrMw4vd Gm55Hq6D3IuDbXfs4gUslJ3pFFct2qBjfFKNEOASLAXHV7ynS9A53VWvukJRD+4KDw8t pUVQpt94Uw8Ch6qMD45rmoo6+0sOspyuvgTNRWppY/XZBfD++lEuFpFIyB2uTZENFaS0 0mWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xcNa/aryHKItA1tZHsSCu27PR5yJtirN4RwdKrDJhk0=; b=sOA01WtWzVEy3iFUkDkLmAoNyrGq1TkCFSXnqLzOmULYk89YkdChY4t+tfi+qnca+7 Q20ODOx0nF2bMbw5XBKOfYn/RUALembjqAcIT8hK3tI0H7x1eavbUI5iIhK021THgUev 6II+yKMKMcc2yrbM3onflJ8ZFjY9Ik2chnBG2K6GWrzwwIFifHuNP2kJGB1RiuzvIG7/ 8zWC8WVn9dKq2U56hQYM70XA2WfcbF6/IqGcdtaCrIRf2NNj5ps4VcT+ywWndYwH8wvn aW1noDHw2qYZqtB7jq71wcf+3C0D3rohnnxLGF6LB12IjRQVJjLuEUT1W1p6HEGHiF7m RmMQ== X-Gm-Message-State: AOAM532V/BHK7GO2hCrp5yiqsXNu5/lGRa+bATHn8i81Js5+2MVVbbEK XB67TaSadfU81YtjRnNa7YU= X-Google-Smtp-Source: ABdhPJz8HqLhEdct9wgkHZoLE4kT4UYsuO7jHF9M4KkHSoXdpahLCdJQCzKloGPeNOI16GEwZEaaCQ== X-Received: by 2002:a17:902:9042:b029:12c:c03:20e2 with SMTP id w2-20020a1709029042b029012c0c0320e2mr12723255plz.36.1627415520080; Tue, 27 Jul 2021 12:52:00 -0700 (PDT) Received: from [192.168.1.112] ([76.21.92.206]) by smtp.gmail.com with ESMTPSA id y6sm3614942pjr.48.2021.07.27.12.51.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jul 2021 12:51:58 -0700 (PDT) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EE3371DF-8722-4709-8947-9CD67EB67772" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Date: Tue, 27 Jul 2021 12:52:56 -0700 In-Reply-To: <4478FB07-361E-4152-89E5-4E0193CF1BE1@juniper.net> Cc: Reshad Rehman , "lsr@ietf.org" , Yingzhen Qu , tom petch , "rtg-bfd@ietf. org" To: John Scudder References: <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93.ref@yahoo.com> <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93@yahoo.com> <40AB32BD-3138-460F-B385-B8BA6D1EA8FB@gmail.com> <781624976.145062.1627397815151@mail.yahoo.com> <4478FB07-361E-4152-89E5-4E0193CF1BE1@juniper.net> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: X-Mailman-Approved-At: Tue, 27 Jul 2021 13:09:36 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 19:52:13 -0000 --Apple-Mail=_EE3371DF-8722-4709-8947-9CD67EB67772 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John, The surgery that I performed on the draft, and can be seen in the = attached files both as a diff and the full file was to remove the = mpls-te module dependency from this draft. We should therefore at least = not be dependent on the ietf-te module. Thanks > On Jul 27, 2021, at 11:49 AM, John Scudder = wrote: >=20 > RFC Editor state is MISSREF, as part of cluster C336: = https://www.rfc-editor.org/cluster_info.php?cid=3DC336 = . If I=E2=80=99m = untangling the information there correctly, I think it=E2=80=99s blocked = on (at least) draft-ietf-teas-yang-te.=20 >=20 > Was the surgery that Tom mentions, expected to clear it out of = MISSREF? If so, please give me some more details (either in this thread = or offline) and I can check in with the RFC Editor. >=20 > Thanks, >=20 > =E2=80=94John >=20 >> On Jul 27, 2021, at 10:56 AM, Reshad Rahman > wrote: >>=20 >>=20 >> Adding John (AD). >>=20 >> On Tuesday, July 27, 2021, 10:45:07 a.m. EDT, tom petch = > wrote: >>=20 >>=20 >> From: Reshad Rahman > >> Sent: 21 May 2021 00:03 >>=20 >> >>=20 >> FYI, Mahesh did the extraction of the mpls-te from = draft-ietf-bfd-yang and it's been submitted to the RFC Editor. >>=20 >> >> Two months have passed and I see no change in the RFC Editor queue. = Whatever was done would appear to have been not enough. I was expecting = an action by the AD to be required and have seen no sign thereof which = may be relevant. >>=20 >> Tom Petch >>=20 >>=20 >> Regards, >> Reshad. >>=20 >> =EF=BB=BFOn 2021-03-22, 3:30 PM, "Rtg-bfd on behalf of Yingzhen Qu" = on behalf of = yingzhen.ietf@gmail.com > wrote: >>=20 >> Hi, >>=20 >> I also support the split of ietf-bfd-mpls-te module from the base = BFD module, so modules like ietf-ospf and ietf-isis can progress. >>=20 >> Thanks, >> Yingzhen >>=20 >> > On Mar 22, 2021, at 2:33 AM, tom petch > wrote: >> > >> > >> > >> > From: Rtg-bfd > on behalf of Reshad Rahman = > >> > Sent: 19 March 2021 18:58 >> > To: rtg-bfd@ietf. org >> > Subject: Draft minutes for BFD @ IETF110 >> > >> > BFD WG, >> > >> > Draft minutes have been posted @ = https://datatracker.ietf.org/doc/minutes-110-bfd/ = >> > >> > Please provide comments to the list by April 2nd. >> > >> > >> > I support Acee's suggestion that the TE part should be split = from the BFD YANG draft so that the other three WG, who have been held = up for years, can progress. >> > >> > Tom Petch >> > >> > Copying the LSR WG. >> > >> > >> > Meeting recording is @ = https://www.youtube.com/watch?v=3DvSqfJJ3gOc0 = >> > >> > Regards, >> > Reshad. >> > >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_EE3371DF-8722-4709-8947-9CD67EB67772 Content-Type: multipart/mixed; boundary="Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C" --Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi John,

The surgery that I performed on the draft, and can be seen in the attached files both as a diff and the full file was to remove the mpls-te module dependency from this draft. We should therefore at least not be dependent on the ietf-te module.

Thanks

--Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C Content-Disposition: attachment; filename*0="Diff_ draft-ietf-bfd-yang-17.txt - draft-ietf-bfd-yang-18.txt.ht"; filename*1=ml Content-Type: text/html; x-unix-mode=0644; name="Diff_ draft-ietf-bfd-yang-17.txt - draft-ietf-bfd-yang-18.txt.html" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Diff: draft-ietf-bfd-yang-17.txt - = draft-ietf-bfd-yang-18.txt=20 =20 =20 =20 =20 =20 =20= = = = = = = = = = = = = = = = = = =
< draft-ietf-bfd-yang-17.txt  =  draft-ietf-bfd-yang-18.txt >
=
skipping to = change at = line 12 =C2=B6 = skipping to change at = line 12 =C2=B6
Internet = Engineering Task Force (IETF) R. Rahman, Ed. = Internet Engineering Task Force (IETF) = R. Rahman, Ed.
Request for = Comments: 0000 Request for Comments: = 0000
Category: = Standards Track L. Zheng, Ed. = Category: Standards Track = L. Zheng, Ed.
ISSN: 2070-1721 = Huawei Technologies ISSN: 2070-1721 = Huawei Technologies
= M. Jethanandani, Ed. M. = Jethanandani, Ed.
= Xoriant Corporation = Xoriant Corporation
= S. Pallagatti = S. Pallagatti
= RtBrick = RtBrick
= G. Mirsky = G. Mirsky
= ZTE Corporation = ZTE Corporation
= November= 2020 = April = 2021
=
YANG Data = Model for Bidirectional Forwarding Detection (BFD) YANG Data Model for Bidirectional Forwarding = Detection (BFD)
=
Abstract = Abstract
=
This document = defines a YANG data model that can be used to configure = This document defines a YANG data model that = can be used to configure
and manage = Bidirectional Forwarding Detection (BFD). and manage Bidirectional Forwarding Detection = (BFD).
=
The YANG = modules in this document conform to the Network Management = The YANG modules in this document conform to = the Network Management
Datastore = Architecture (NMDA) (RFC 8342). = Datastore Architecture (NMDA) (RFC 8342).
=
skipping to = change at = line 40 =C2=B6 = skipping to change at = line 40 =C2=B6
received = public review and has been approved for publication by the = received public review and has been approved = for publication by the
Internet = Engineering Steering Group (IESG). Further information on = Internet Engineering Steering Group (IESG). = Further information on
Internet = Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC = 7841.
=
Information = about the current status of this document, any errata, Information about the current status of this = document, any errata,
and how to = provide feedback on it may be obtained at and how to provide feedback on it may be obtained = at
= https://www.rfc-editor.org/info/rfc0000. https://www.rfc-editor.org/info/rfc0000.
=
Copyright = Notice Copyright Notice
=
Copyright = (c) 2020 IETF Trust and the persons = identified as the Copyright (c) = 2021 IETF Trust and the persons identified = as the
document = authors. All rights reserved. = document authors. All rights reserved.
=
This document = is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF = Trust's Legal
Provisions = Relating to IETF Documents = Provisions Relating to IETF Documents
= (https://trustee.ietf.org/license-info) in effect on the date = of = (https://trustee.ietf.org/license-info) in effect on the date of
publication of = this document. Please review these documents publication of this document. Please review these = documents
carefully, as = they describe your rights and restrictions with respect = carefully, as they describe your rights and = restrictions with respect
to this = document. Code Components extracted from this document must = to this document. Code Components extracted = from this document must
include = Simplified BSD License text as described in Section 4.e of = include Simplified BSD License text as = described in Section 4.e of
the Trust = Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without = warranty as
=
skipping to = change at = line 62 =C2=B6 = skipping to change at = line 62 =C2=B6
=
Table of = Contents Table of Contents
=
1. = Introduction 1. = Introduction
1.1. Tree = Diagrams 1.1. Tree = Diagrams
2. Design of = the Data Model 2. Design of the = Data Model
2.1. Design = of the Configuration Model 2.1. = Design of the Configuration Model
2.1.1. = Common BFD Configuration Parameters = 2.1.1. Common BFD Configuration Parameters
2.1.2. = Single-Hop IP 2.1.2. = Single-Hop IP
2.1.3. = Multihop IP 2.1.3. Multihop = IP
2.1.4. = MPLS Traffic Engineering Tunnels = 2.1.4. MPLS Label Switched = Paths
2.1.5. MPLS Label Switched = Paths 2.1.5. Link Aggregation Groups
2.1.6. Link Aggregation Groups =
2.2. Design = of the Operational State Model = 2.2. Design of the Operational State Model
2.3. = Notifications 2.3. = Notifications
2.4. RPC = Operations 2.4. RPC = Operations
2.5. BFD = Top-Level Hierarchy 2.5. BFD = Top-Level Hierarchy
2.6. BFD IP = Single-Hop Hierarchy 2.6. BFD IP = Single-Hop Hierarchy
2.7. BFD IP = Multihop Hierarchy 2.7. BFD IP = Multihop Hierarchy
2.8. = BFD-over-LAG Hierarchy 2.8. = BFD-over-LAG Hierarchy
2.9. = BFD-over-MPLS-LSPs Hierarchy 2.9. = BFD-over-MPLS-LSPs Hierarchy
2.10. = BFD-over-MPLS-TE Hierarchy = 2.10. Interaction with Other YANG = Modules
2.11. Interaction with Other YANG = Modules 2.10.1. "ietf-interfaces" Module
2.11.1. "ietf-interfaces" Module = 2.10.2. = "ietf-ip" Module
2.11.2. "ietf-ip" Module 2.10.3. = "ietf-mpls" Module
2.11.3. "ietf-mpls" Module 2.11. IANA BFD YANG = Module
2.11.4. "ietf-te" Module 2.12. BFD Types YANG = Module
2.12. IANA BFD YANG Module = 2.13. BFD = Top-Level YANG Module
2.13. BFD Types YANG Module 2.14. BFD IP = Single-Hop YANG Module
2.14. BFD Top-Level YANG Module = 2.15. BFD = IP Multihop YANG Module
2.15. BFD IP Single-Hop YANG Module = 2.16. = BFD-over-LAG YANG Module
2.16. BFD IP Multihop YANG Module = 2.17. = BFD-over-MPLS YANG Module
2.17. BFD-over-LAG YANG Module
2.18. BFD-over-MPLS YANG = Module
2.19. BFD-over-MPLS-TE YANG Module =
3. Data Model = Examples 3. Data Model = Examples
3.1. IP = Single-Hop 3.1. IP = Single-Hop
3.2. IP = Multihop 3.2. IP = Multihop
3.3. = LAG 3.3. LAG
3.4. = MPLS 3.4. MPLS
4. Security = Considerations 4. Security = Considerations
5. IANA = Considerations 5. IANA = Considerations
5.1. = IANA-Maintained "iana-bfd-types" Module = 5.1. IANA-Maintained "iana-bfd-types" Module
6. = References 6. References
6.1. = Normative References 6.1. = Normative References
=
skipping to = change at = line 156 =C2=B6 = skipping to change at = line 152 =C2=B6
=
This document = uses the graphical representation of data models, as This document uses the graphical representation of = data models, as
defined in = [RFC8340]. defined in = [RFC8340].
=
2. Design of the = Data Model 2. Design of the Data = Model
=
Since BFD is = used for liveness detection of various forwarding paths, = Since BFD is used for liveness detection of = various forwarding paths,
there is no = uniform key to identify a BFD session, and so the BFD there is no uniform key to identify a BFD session, = and so the BFD
data model is = split into multiple YANG modules where each module data model is split into multiple YANG modules where = each module
corresponds to = one type of forwarding path. For example, BFD for IP corresponds to one type of forwarding path. For = example, BFD for IP
single-hop = is in one YANG module, and BFD for MPLS-TE = is in another single-hop is in one = YANG module, and BFD for MPLS is in = another YANG
YANG module. = The main difference between these modules is how a BFD = module. The main difference between these = modules is how a BFD
session is = uniquely identified, i.e., the key for the list containing = session is uniquely identified, i.e., the = key for the list containing
the BFD = sessions for that forwarding path. To avoid duplication of = the BFD sessions for that forwarding path. = To avoid duplication of
BFD = definitions, we have common types and groupings that are used = by BFD definitions, we have common = types and groupings that are used by
all the = modules. all the modules.
=
A new = control-plane protocol, "bfdv1", is defined, and a "bfd" = A new control-plane protocol, "bfdv1", is = defined, and a "bfd"
container is = created under "control-plane-protocol" as specified in container is created under "control-plane-protocol" = as specified in
"A YANG Data = Model for Routing Management (NMDA Version)" [RFC8349]. = "A YANG Data Model for Routing Management = (NMDA Version)" [RFC8349].
This new "bfd" = container is augmented by the following YANG modules This new "bfd" container is augmented by the = following YANG modules
for their = respective specific information: = for their respective specific information:
=
1. The = "ietf-bfd-ip-sh" module (Section 2.15) = augments "/routing/ 1. The = "ietf-bfd-ip-sh" module (Section 2.14) = augments "/routing/
= control-plane-protocols/control-plane-protocol/bfd/" with the = = control-plane-protocols/control-plane-protocol/bfd/" with the
"ip-sh" = container for BFD sessions over IP single-hop. "ip-sh" container for BFD sessions over IP = single-hop.
=
2. The = "ietf-bfd-ip-mh" module (Section 2.16) = augments "/routing/ 2. The = "ietf-bfd-ip-mh" module (Section 2.15) = augments "/routing/
= control-plane-protocols/control-plane-protocol/bfd/" with the = = control-plane-protocols/control-plane-protocol/bfd/" with the
"ip-mh" = container for BFD sessions over IP multihop. "ip-mh" container for BFD sessions over IP = multihop.
=
3. The = "ietf-bfd-lag" module (Section 2.17) = augments "/routing/ 3. The = "ietf-bfd-lag" module (Section 2.16) = augments "/routing/
= control-plane-protocols/control-plane-protocol/bfd/" with the = = control-plane-protocols/control-plane-protocol/bfd/" with the
"lag" = container for BFD sessions over a LAG. = "lag" container for BFD sessions over a LAG.
=
4. The = "ietf-bfd-mpls" module (Section 2.18) = augments "/routing/ 4. The = "ietf-bfd-mpls" module (Section 2.17) = augments "/routing/
= control-plane-protocols/control-plane-protocol/bfd/" with the = = control-plane-protocols/control-plane-protocol/bfd/" with the
"mpls" = container for BFD-over-MPLS LSPs. = "mpls" container for BFD-over-MPLS LSPs.
=
5. The "ietf-bfd-mpls-te" module (Section 2.19) = augments "/routing/
= control-plane-protocols/control-plane-protocol/bfd/" with = the
"mpls-te" container for BFD over = MPLS-TE.
= =
BFD can = operate in the following contexts: = BFD can operate in the following contexts:
=
1. At the = network device level. 1. At the = network device level.
=
2. In logical = network elements (LNEs) as described in "YANG Model 2. In logical network elements (LNEs) as described = in "YANG Model
for = Logical Network Elements" [RFC8530]. = for Logical Network Elements" [RFC8530].
=
3. In network = instances as described in "YANG Data Model for Network 3. In network instances as described in "YANG Data = Model for Network
Instances" = [RFC8529]. Instances" = [RFC8529].
=
=
skipping to = change at = line 229 =C2=B6 = skipping to change at = line 221 =C2=B6
convergence = time of the BFD clients when a failure occurs. Other convergence time of the BFD clients when a failure = occurs. Other
parameters, = such as BFD authentication, are not specific to the parameters, such as BFD authentication, are not = specific to the
requirements = of the BFD client. Configuration of BFD for all clients = requirements of the BFD client. = Configuration of BFD for all clients
should be = centralized. However, this is a problem for BFD clients = should be centralized. However, this is a = problem for BFD clients
that = auto-discover their peers. For example, IGPs do not have the = that auto-discover their peers. For = example, IGPs do not have the
peer address = configured; instead, the IGP is enabled on an interface, = peer address configured; instead, the IGP is = enabled on an interface,
and the IGP = peers are auto-discovered. So, for an operator to and the IGP peers are auto-discovered. So, for an = operator to
configure BFD = to an IGP peer, the operator would first have to configure BFD to an IGP peer, the operator would = first have to
determine the = peer addresses. And when a new peer is discovered, BFD = determine the peer addresses. And when a = new peer is discovered, BFD
configuration = would need to be added. To avoid this issue, we define = configuration would need to be added. To = avoid this issue, we define
the grouping = "client-cfg-parms" in Section 2.13 for BFD = clients to the grouping = "client-cfg-parms" in Section 2.12 for BFD = clients to
configure BFD: = this allows BFD clients, such as the IGPs, to have configure BFD: this allows BFD clients, such as the = IGPs, to have
configuration = (multiplier and intervals) for the BFD sessions they configuration (multiplier and intervals) for the BFD = sessions they
need. For = example, when a new IGP peer is discovered, the IGP would = need. For example, when a new IGP peer is = discovered, the IGP would
create a BFD = session to the newly discovered peer; similarly, when an = create a BFD session to the newly discovered = peer; similarly, when an
IGP peer goes = away, the IGP would remove the BFD session to that IGP peer goes away, the IGP would remove the BFD = session to that
peer. The = mechanism for how the BFD sessions are created and removed = peer. The mechanism for how the BFD = sessions are created and removed
by the BFD = clients is outside the scope of this document, but this = by the BFD clients is outside the scope of = this document, but this
would = typically be done by using an API implemented by the BFD module = would typically be done by using an API = implemented by the BFD module
on the system. = In the case of BFD clients that create BFD sessions on the system. In the case of BFD clients that = create BFD sessions
via their own = configuration, authentication parameters (if required) via their own configuration, authentication = parameters (if required)
=
skipping to = change at = line 262 =C2=B6 = skipping to change at = line 254 =C2=B6
= required-min-rx-interval = required-min-rx-interval
This is the = Required Min RX Interval as defined in BFD [RFC5880]. This is the Required Min RX Interval as defined in = BFD [RFC5880].
=
Although BFD = [RFC5880] allows for different values for transmit and Although BFD [RFC5880] allows for different values = for transmit and
receive = intervals, some implementations allow users to specify just = receive intervals, some implementations = allow users to specify just
one interval = that is used for both transmit and receive intervals, or = one interval that is used for both transmit = and receive intervals, or
separate = values for transmit and receive intervals. The BFD YANG = separate values for transmit and receive = intervals. The BFD YANG
data model = supports this: there is a choice between "min-interval", = data model supports this: there is a choice = between "min-interval",
used for both = transmit and receive intervals, and "desired-min-tx- used for both transmit and receive intervals, and = "desired-min-tx-
interval" and = "required-min-rx-interval". This is supported via the interval" and "required-min-rx-interval". This is = supported via the
= "base-cfg-parms" grouping (Section 2.13), = which is used by the YANG = "base-cfg-parms" grouping (Section 2.12), = which is used by the YANG
modules for = the various forwarding paths. = modules for the various forwarding paths.
=
For BFD = authentication, we have the following: = For BFD authentication, we have the following:
=
= key-chain key-chain
This is a = reference to "key-chain" as defined in "YANG Data Model = This is a reference to "key-chain" as = defined in "YANG Data Model
for Key = Chains" [RFC8177]. The keys, cryptographic algorithms, = for Key Chains" [RFC8177]. The keys, = cryptographic algorithms,
key = lifetime, etc. are all defined in the "key-chain" model. = key lifetime, etc. are all defined in the = "key-chain" model.
=
= meticulous meticulous
=
skipping to = change at = line 323 =C2=B6 = skipping to change at = line 315 =C2=B6
We use the = configuration parameters defined in Section 2.1.1. We use the configuration parameters defined in = Section 2.1.1.
=
This document = also provides the following parameters: = This document also provides the following parameters:
=
= tx-ttl tx-ttl
TTL of = outgoing BFD control packets. = TTL of outgoing BFD control packets.
=
= rx-ttl rx-ttl
Minimum TTL = of incoming BFD control packets. = Minimum TTL of incoming BFD control packets.
=
2.1.4. MPLS = Traffic Engineering Tunnels = 2.1.4. MPLS Label Switched Paths
For MPLS-TE tunnels, BFD is configured under the = MPLS-TE tunnel,
since the desired failure detection parameters are a = property of the
MPLS-TE tunnel. This is achieved by augmenting the = MPLS-TE data
model in "A YANG Data Model for Traffic Engineering = Tunnels, Label
Switched Paths, and Interfaces" [RFCYYY2]. In the = case of BFD
parameters that are specific to the TE application, = e.g., whether to
tear down the tunnel in the event of a BFD session = failure, these
parameters will be defined in the YANG data model = for the MPLS-TE
application.
In addition to the usual BFD parameters, we have the = following per
MPLS-TE tunnel:
encap
Encapsulation for the BFD packets: a choice = between IP, a Generic
Associated Channel (G-ACh), and IP with a G-ACh = as per "MPLS
Generic Associated Channel" = [RFC5586].
For general MPLS-TE data, an "mpls-te" data node is = added under the
"bfd" node, as described in Section 2. Since some = MPLS-TE tunnels
are unidirectional, there is no MPLS-TE = configuration for these
tunnels on the egress node (note that this does not = apply to
bidirectional MPLS-TP tunnels). The BFD parameters = for the egress
node are added under "mpls-te". =
2.1.5. MPLS Label Switched Paths =
=
Here, we = address MPLS LSPs whose Forwarding Equivalence Class (FEC) = Here, we address MPLS LSPs whose Forwarding = Equivalence Class (FEC)
[RFC3031] is = an IP address. The "bfd" node (Section 2) is augmented = [RFC3031] is an IP address. The "bfd" node = (Section 2) is augmented
with "mpls", = which contains a list of sessions uniquely identified by = with "mpls", which contains a list of = sessions uniquely identified by
an IP prefix. = Because of multiple paths, there could be multiple an IP prefix. Because of multiple paths, there could = be multiple
MPLS sessions = to an MPLS FEC. We identify this set of sessions as a MPLS sessions to an MPLS FEC. We identify this set = of sessions as a
= "session-group". = "session-group".
=
Since these = LSPs are unidirectional, there is no LSP configuration on = Since these LSPs are unidirectional, there = is no LSP configuration on
the egress = node. the egress node.
=
The BFD = parameters for the egress node are added under "mpls". The BFD parameters for the egress node are added = under "mpls".
=
2.1.6. Link Aggregation Groups 2.1.5. Link Aggregation = Groups
=
Per = "Bidirectional Forwarding Detection (BFD) on Link Aggregation = Per "Bidirectional Forwarding Detection = (BFD) on Link Aggregation
Group (LAG) = Interfaces" [RFC7130], configuring BFD on a LAG consists = Group (LAG) Interfaces" [RFC7130], = configuring BFD on a LAG consists
of having = micro-BFD sessions on each LAG member link. Since the BFD = of having micro-BFD sessions on each LAG = member link. Since the BFD
parameters are = an attribute of the LAG, they should be under the LAG. parameters are an attribute of the LAG, they should = be under the LAG.
However, there = is no LAG YANG data model that we can augment. So, a However, there is no LAG YANG data model that we can = augment. So, a
"lag" data = node is added to the "bfd" node; see Section 2. The "lag" data node is added to the "bfd" node; see = Section 2. The
configuration = is per LAG: we have a list of LAGs. The destination IP = configuration is per LAG: we have a list of = LAGs. The destination IP
address of the = micro-BFD sessions is configured per LAG and per address of the micro-BFD sessions is configured per = LAG and per
address family = (IPv4 and IPv6). address family = (IPv4 and IPv6).
=
skipping to = change at = line 477 =C2=B6 = skipping to change at = line 442 =C2=B6
| = +--rw (interval-config-type)? = | +--rw (interval-config-type)?
| | = +--:(tx-rx-intervals) | = | +--:(tx-rx-intervals)
| | = | +--rw desired-min-tx-interval? uint32 | | | +--rw desired-min-tx-interval? = uint32
| | = | +--rw required-min-rx-interval? uint32 | | | +--rw required-min-rx-interval? = uint32
| | = +--:(single-interval) {single-minimum-interval}? | | +--:(single-interval) = {single-minimum-interval}?
| | = +--rw min-interval? uint32 | | +--rw min-interval? = uint32
| = +--rw demand-enabled? boolean | +--rw demand-enabled? = boolean
| | = {demand-mode}? | | = {demand-mode}?
| = +--rw admin-down? boolean | +--rw admin-down? = boolean
| = +--rw authentication! {authentication}? = | +--rw authentication! {authentication}?
| = | +--rw key-chain? kc:key-chain-ref | | +--rw key-chain? key-chain:key-chain-ref
| | = +--rw meticulous? boolean = | | +--rw meticulous? boolean
| = +--ro path-type? identityref | +--ro path-type? = identityref
| = +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? = boolean
| = +--ro local-discriminator? discriminator | +--ro local-discriminator? = discriminator
| = +--ro remote-discriminator? discriminator | +--ro remote-discriminator? = discriminator
| = +--ro remote-multiplier? multiplier | +--ro remote-multiplier? = multiplier
| = +--ro demand-capability? boolean | +--ro demand-capability? = boolean
| | = {demand-mode}? | | = {demand-mode}?
| = +--ro source-port? inet:port-number = | +--ro source-port? = inet:port-number
| = +--ro dest-port? inet:port-number = | +--ro dest-port? = inet:port-number
=
skipping to = change at = line 521 =C2=B6 = skipping to change at = line 486 =C2=B6
| = | yang:date-and-time = | | yang:date-and-time
| = +--ro down-count? yang:counter32 | +--ro down-count? = yang:counter32
| = +--ro admin-down-count? yang:counter32 | +--ro admin-down-count? = yang:counter32
| = +--ro receive-packet-count? yang:counter64 | +--ro receive-packet-count? = yang:counter64
| = +--ro send-packet-count? yang:counter64 | +--ro send-packet-count? = yang:counter64
| = +--ro receive-invalid-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? = yang:counter64
| = +--ro send-failed-packet-count? yang:counter64 | +--ro send-failed-packet-count? = yang:counter64
+--rw = interfaces* [interface] = +--rw interfaces* [interface]
= +--rw interface if:interface-ref +--rw interface = if:interface-ref
= +--rw authentication! {authentication}? = +--rw authentication! {authentication}?
= +--rw key-chain? kc:key-chain-ref +--rw key-chain? key-chain:key-chain-ref
= +--rw meticulous? boolean = +--rw meticulous? boolean
=
= notifications: = notifications:
+---n = singlehop-notification +---n = singlehop-notification
+--ro = local-discr? discriminator +--ro local-discr? = discriminator
+--ro = remote-discr? discriminator +--ro remote-discr? = discriminator
+--ro = new-state? state = +--ro new-state? state
+--ro = state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? = iana-bfd-types:diagnostic
+--ro = time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? = yang:date-and-time
+--ro = dest-addr? inet:ip-address +--ro dest-addr? = inet:ip-address
=
skipping = to change at = line 571 =C2=B6 = skipping to change at = line 536 =C2=B6
= +--rw (interval-config-type)? = +--rw (interval-config-type)?
| = +--:(tx-rx-intervals) = | +--:(tx-rx-intervals)
| = | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? = uint32
| = | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? = uint32
| = +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) = {single-minimum-interval}?
| = +--rw min-interval? uint32 | +--rw min-interval? = uint32
= +--rw demand-enabled? boolean +--rw demand-enabled? = boolean
| = {demand-mode}? | = {demand-mode}?
= +--rw admin-down? boolean +--rw admin-down? = boolean
= +--rw authentication! {authentication}? = +--rw authentication! {authentication}?
= | +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| = +--rw meticulous? boolean = | +--rw meticulous? boolean
= +--rw tx-ttl? bfd-types:hops +--rw tx-ttl? = bfd-types:hops
= +--rw rx-ttl bfd-types:hops +--rw rx-ttl = bfd-types:hops
= +--ro sessions* [] = +--ro sessions* []
= +--ro path-type? identityref +--ro path-type? = identityref
= +--ro ip-encapsulation? boolean = +--ro ip-encapsulation? boolean
= +--ro local-discriminator? discriminator +--ro local-discriminator? = discriminator
= +--ro remote-discriminator? discriminator +--ro remote-discriminator? = discriminator
= +--ro remote-multiplier? multiplier +--ro remote-multiplier? = multiplier
= +--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean = {demand-mode}?
=
skipping = to change at = line 673 =C2=B6 = skipping to change at = line 638 =C2=B6
= +--rw (interval-config-type)? = +--rw (interval-config-type)?
| = +--:(tx-rx-intervals) = | +--:(tx-rx-intervals)
| = | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? = uint32
| = | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? = uint32
| = +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) = {single-minimum-interval}?
| = +--rw min-interval? uint32 | +--rw min-interval? = uint32
= +--rw demand-enabled? boolean +--rw demand-enabled? = boolean
| = {demand-mode}? | = {demand-mode}?
= +--rw admin-down? boolean +--rw admin-down? = boolean
= +--rw authentication! {authentication}? = +--rw authentication! {authentication}?
= | +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| = +--rw meticulous? boolean = | +--rw meticulous? boolean
= +--rw use-ipv4? boolean +--rw use-ipv4? = boolean
= +--rw use-ipv6? boolean +--rw use-ipv6? = boolean
= +--ro member-links* [member-link] = +--ro member-links* [member-link]
= +--ro member-link if:interface-ref +--ro member-link = if:interface-ref
= +--ro micro-bfd-ipv4 = +--ro micro-bfd-ipv4
= | +--ro path-type? identityref | +--ro path-type? = identityref
= | +--ro ip-encapsulation? boolean | +--ro ip-encapsulation? = boolean
= | +--ro local-discriminator? discriminator | +--ro local-discriminator? = discriminator
= | +--ro remote-discriminator? discriminator | +--ro remote-discriminator? = discriminator
=
skipping = to change at = line 816 =C2=B6 = skipping to change at = line 781 =C2=B6
+--rw = egress +--rw egress
| = +--rw enabled? boolean | +--rw enabled? = boolean
| = +--rw local-multiplier? multiplier | +--rw local-multiplier? = multiplier
| = +--rw (interval-config-type)? = | +--rw (interval-config-type)?
| | = +--:(tx-rx-intervals) | | = +--:(tx-rx-intervals)
| | | = +--rw desired-min-tx-interval? uint32 | | | +--rw desired-min-tx-interval? = uint32
| | | = +--rw required-min-rx-interval? uint32 | | | +--rw required-min-rx-interval? = uint32
| | = +--:(single-interval) {single-minimum-interval}? | | +--:(single-interval) = {single-minimum-interval}?
| | = +--rw min-interval? uint32 | | +--rw min-interval? = uint32
| = +--rw authentication! {authentication}? = | +--rw authentication! {authentication}?
| = +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| = +--rw meticulous? boolean = | +--rw meticulous? boolean
+--rw = session-groups +--rw = session-groups
= +--rw session-group* [mpls-fec] = +--rw session-group* [mpls-fec]
= +--rw mpls-fec inet:ip-prefix +--rw mpls-fec = inet:ip-prefix
= +--rw local-multiplier? multiplier +--rw local-multiplier? = multiplier
= +--rw (interval-config-type)? = +--rw (interval-config-type)?
| = +--:(tx-rx-intervals) = | +--:(tx-rx-intervals)
| = | +--rw desired-min-tx-interval? uint32 | | +--rw desired-min-tx-interval? = uint32
| = | +--rw required-min-rx-interval? uint32 | | +--rw required-min-rx-interval? = uint32
| = +--:(single-interval) {single-minimum-interval}? | +--:(single-interval) = {single-minimum-interval}?
| = +--rw min-interval? uint32 | +--rw min-interval? = uint32
= +--rw demand-enabled? boolean +--rw demand-enabled? = boolean
| = {demand-mode}? | = {demand-mode}?
= +--rw admin-down? boolean +--rw admin-down? = boolean
= +--rw authentication! {authentication}? = +--rw authentication! {authentication}?
= | +--rw key-chain? kc:key-chain-ref | +--rw key-chain? key-chain:key-chain-ref
| = +--rw meticulous? boolean = | +--rw meticulous? boolean
= +--ro sessions* [] = +--ro sessions* []
= +--ro path-type? identityref +--ro path-type? = identityref
= +--ro ip-encapsulation? boolean = +--ro ip-encapsulation? boolean
= +--ro local-discriminator? discriminator +--ro local-discriminator? = discriminator
= +--ro remote-discriminator? discriminator +--ro remote-discriminator? = discriminator
= +--ro remote-multiplier? multiplier +--ro remote-multiplier? = multiplier
= +--ro demand-capability? boolean {demand-mode}? +--ro demand-capability? boolean = {demand-mode}?
= +--ro source-port? inet:port-number +--ro source-port? = inet:port-number
= +--ro dest-port? inet:port-number +--ro dest-port? = inet:port-number
=
skipping = to change at = line 894 =C2=B6 = skipping to change at = line 859 =C2=B6
+--ro = remote-discr? discriminator +--ro remote-discr? = discriminator
+--ro = new-state? state = +--ro new-state? state
+--ro = state-change-reason? iana-bfd-types:diagnostic +--ro state-change-reason? = iana-bfd-types:diagnostic
+--ro = time-of-last-state-change? yang:date-and-time +--ro time-of-last-state-change? = yang:date-and-time
+--ro = dest-addr? inet:ip-address +--ro dest-addr? = inet:ip-address
+--ro = source-addr? inet:ip-address +--ro source-addr? = inet:ip-address
+--ro = session-index? uint32 = +--ro session-index? uint32
+--ro = path-type? identityref +--ro path-type? = identityref
+--ro = mpls-dest-address? inet:ip-address +--ro mpls-dest-address? = inet:ip-address
=
2.10. BFD-over-MPLS-TE Hierarchy 2.10. Interaction with Other YANG Modules
The "/te/tunnels/tunnel" node as defined in "A YANG = Data Model for
Traffic Engineering Tunnels, Label Switched Paths, = and Interfaces"
[RFCYYY2] is augmented. BFD is configured per = MPLS-TE tunnel, and
BFD session operational state data is provided per = MPLS-TE LSP.
module: ietf-bfd-mpls-te
augment = /rt:routing/rt:control-plane-protocols
= /rt:control-plane-protocol/bfd:bfd:
+--rw mpls-te
+--rw egress
| +--rw enabled? = boolean
| +--rw local-multiplier? = multiplier
| +--rw = (interval-config-type)?
| | +--:(tx-rx-intervals) =
| | | +--rw desired-min-tx-interval? = uint32
| | | +--rw required-min-rx-interval? = uint32
| | +--:(single-interval) = {single-minimum-interval}?
| | +--rw min-interval? = uint32
| +--rw authentication! = {authentication}?
| +--rw key-chain? = kc:key-chain-ref
| +--rw meticulous? = boolean
+--ro summary
+--ro number-of-sessions? = yang:gauge32
+--ro number-of-sessions-up? = yang:gauge32
+--ro number-of-sessions-down? = yang:gauge32
+--ro number-of-sessions-admin-down? = yang:gauge32
augment = /te:te/te:tunnels/te:tunnel:
+--rw local-multiplier? = multiplier
+--rw (interval-config-type)? =
| +--:(tx-rx-intervals) =
| | +--rw desired-min-tx-interval? = uint32
| | +--rw required-min-rx-interval? = uint32
| +--:(single-interval) = {single-minimum-interval}?
| +--rw min-interval? = uint32
+--rw demand-enabled? boolean = {demand-mode}?
+--rw admin-down? = boolean
+--rw authentication! = {authentication}?
| +--rw key-chain? = kc:key-chain-ref
| +--rw meticulous? boolean =
+--rw encap? = identityref
augment /te:te/te:lsps/te:lsp: =
+--ro path-type? = identityref
+--ro ip-encapsulation? = boolean
+--ro local-discriminator? = discriminator
+--ro remote-discriminator? = discriminator
+--ro remote-multiplier? = multiplier
+--ro demand-capability? boolean = {demand-mode}?
+--ro source-port? = inet:port-number
+--ro dest-port? = inet:port-number
+--ro session-running
| +--ro session-index? = uint32
| +--ro local-state? = state
| +--ro remote-state? = state
| +--ro local-diagnostic? = iana-bfd-types:diagnostic
| +--ro remote-diagnostic? = iana-bfd-types:diagnostic
| +--ro remote-authenticated? = boolean
| +--ro remote-authentication-type? = iana-bfd-types:auth-type
| | {authentication}? =
| +--ro detection-mode? = enumeration
| +--ro negotiated-tx-interval? = uint32
| +--ro negotiated-rx-interval? = uint32
| +--ro detection-time? = uint32
| +--ro echo-tx-interval-in-use? uint32 = {echo-mode}?
+--ro session-statistics =
| +--ro create-time? = yang:date-and-time
| +--ro last-down-time? = yang:date-and-time
| +--ro last-up-time? = yang:date-and-time
| +--ro down-count? = yang:counter32
| +--ro admin-down-count? = yang:counter32
| +--ro receive-packet-count? = yang:counter64
| +--ro send-packet-count? = yang:counter64
| +--ro receive-invalid-packet-count? = yang:counter64
| +--ro send-failed-packet-count? = yang:counter64
+--ro mpls-dest-address? = inet:ip-address
notifications:
+---n mpls-te-notification =
+--ro local-discr? = discriminator
+--ro remote-discr? = discriminator
+--ro new-state? = state
+--ro state-change-reason? = iana-bfd-types:diagnostic
+--ro time-of-last-state-change? = yang:date-and-time
+--ro dest-addr? = inet:ip-address
+--ro source-addr? = inet:ip-address
+--ro session-index? = uint32
+--ro path-type? = identityref
+--ro mpls-dest-address? = inet:ip-address
+--ro tunnel-name? = string
2.11. Interaction with Other YANG = Modules
=
"Generic YANG = Data Model for the Management of Operations, "Generic YANG Data Model for the Management of = Operations,
= Administration, and Maintenance (OAM) Protocols That Use = Administration, and Maintenance (OAM) = Protocols That Use
Connectionless = Communications" [RFC8532] describes how the Layer- Connectionless Communications" [RFC8532] describes = how the Layer-
Independent = OAM Management in the Multi-Layer Environment (LIME) Independent OAM Management in the Multi-Layer = Environment (LIME)
connectionless = OAM model could be extended to support BFD. connectionless OAM model could be extended to support = BFD.
=
Also, the = operation of the BFD data model depends on configuration = Also, the operation of the BFD data model = depends on configuration
parameters = that are defined in other YANG modules. = parameters that are defined in other YANG modules.
=
2.11.1. "ietf-interfaces" Module 2.10.1. = "ietf-interfaces" Module
=
The following = boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A = YANG Data Model
for Interface = Management" [RFC8343]: for = Interface Management" [RFC8343]:
=
= /if:interfaces/if:interface/if:enabled = /if:interfaces/if:interface/if:enabled
If this = configuration is set to "false", no BFD packets can be If this configuration is set to "false", no BFD = packets can be
transmitted = or received on that interface. = transmitted or received on that interface.
=
2.11.2. "ietf-ip" Module 2.10.2. "ietf-ip" = Module
=
The following = boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A = YANG Data Model
for IP = Management" [RFC8344]: for IP = Management" [RFC8344]:
=
= /if:interfaces/if:interface/ip:ipv4/ip:enabled = /if:interfaces/if:interface/ip:ipv4/ip:enabled
If this = configuration is set to "false", no BFD IPv4 packets can = If this configuration is set to "false", = no BFD IPv4 packets can
be = transmitted or received on that interface. be transmitted or received on that = interface.
=
= /if:interfaces/if:interface/ip:ipv4/ip:forwarding = /if:interfaces/if:interface/ip:ipv4/ip:forwarding
If this = configuration is set to "false", no BFD IPv4 packets can = If this configuration is set to "false", = no BFD IPv4 packets can
be = transmitted or received on that interface. be transmitted or received on that = interface.
=
= /if:interfaces/if:interface/ip:ipv6/ip:enabled = /if:interfaces/if:interface/ip:ipv6/ip:enabled
If this = configuration is set to "false", no BFD IPv6 packets can = If this configuration is set to "false", = no BFD IPv6 packets can
be = transmitted or received on that interface. be transmitted or received on that = interface.
=
= /if:interfaces/if:interface/ip:ipv6/ip:forwarding = /if:interfaces/if:interface/ip:ipv6/ip:forwarding
If this = configuration is set to "false", no BFD IPv6 packets can = If this configuration is set to "false", = no BFD IPv6 packets can
be = transmitted or received on that interface. be transmitted or received on that = interface.
=
2.11.3. "ietf-mpls" Module 2.10.3. "ietf-mpls" = Module
=
The following = boolean configuration is defined in "A YANG Data Model The following boolean configuration is defined in "A = YANG Data Model
for MPLS = Base" [RFCYYY1]: for MPLS Base" [RFC8960]:
=
= /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/ = /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/
= mpls:mpls-enabled = mpls:mpls-enabled
If this = configuration is set to "false", no BFD MPLS packets can = If this configuration is set to "false", = no BFD MPLS packets can
be = transmitted or received on that interface. be transmitted or received on that = interface.
=
2.11.4. "ietf-te" Module 2.11. IANA BFD YANG = Module
The following configuration is defined in the = "ietf-te" YANG module
provided in "A YANG Data Model for Traffic = Engineering Tunnels, Label
Switched Paths, and Interfaces" = [RFCYYY2]:
= /ietf-te:te/ietf-te:tunnels/ietf-te:tunnel/ietf-te:admin-state
If this configuration is not set to = "tunnel-admin-state-up", no
BFD MPLS packets can be transmitted or received = on that tunnel.
2.12. IANA BFD YANG Module
=
This YANG = module imports typedefs from [RFC5880] and references This YANG module imports typedefs from [RFC5880] and = references
= [RFC6428]. [RFC6428].
=
<CODE = BEGINS> file "iana-bfd-types@2018-08-01.yang" = <CODE BEGINS> file "iana-bfd-types@2021-04-08.yang"
module = iana-bfd-types { module = iana-bfd-types {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:iana-bfd-types"; namespace = "urn:ietf:params:xml:ns:yang:iana-bfd-types";
prefix = "iana-bfd-types"; prefix = "iana-bfd-types";
=
organization = "IANA"; organization = "IANA";
=
= contact contact
"Internet = Assigned Numbers Authority = "Internet Assigned Numbers Authority
=
skipping = to change at = line 1078 =C2=B6 = skipping to change at = line 942 =C2=B6
= <mailto:iana@iana.org>"; = <mailto:iana@iana.org>";
=
= description description
"This = module defines YANG data types for IANA-registered "This module defines YANG data types for = IANA-registered
BFD = parameters. BFD = parameters.
=
This YANG = module is maintained by IANA and reflects the This YANG module is maintained by IANA and = reflects the
'BFD = Diagnostic Codes' and 'BFD Authentication Types' 'BFD Diagnostic Codes' and 'BFD Authentication = Types'
= registries. = registries.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 0000: = YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* Type = definitions * Type = definitions
*/ = */
=
skipping = to change at = line 1164 =C2=B6 = skipping to change at = line 1028 =C2=B6
value = 9; value 9;
= description = description
= "Mis-connectivity defect as specified in RFC 6428."; "Mis-connectivity defect as specified in = RFC 6428.";
= reference reference
"RFC = 6428: Proactive Connectivity Verification, Continuity "RFC 6428: Proactive Connectivity = Verification, Continuity
= Check, and Remote Defect Indication for the MPLS Transport = Check, and Remote Defect = Indication for the MPLS Transport
= Profile"; = Profile";
= } }
} = }
= description description
"BFD = diagnostic codes as defined in RFC 5880. = Values are "BFD = diagnostic codes as defined in RFC 5880. Values are
= maintained in the 'BFD Diagnostic Codes' IANA registry. = maintained in the 'BFD Diagnostic = Codes' IANA registry.
Range = is 0 to 31."; Range is 0 to = 31.";
= reference reference
"RFC = 5880: Bidirectional Forwarding Detection (BFD)"; "RFC 5880: Bidirectional Forwarding Detection = (BFD)";
} = }
=
typedef = auth-type { typedef auth-type = {
type = enumeration { type enumeration = {
enum = reserved { enum reserved = {
value = 0; value 0;
=
skipping = to change at = line 1205 =C2=B6 = skipping to change at = line 1069 =C2=B6
= description = description
= "Keyed SHA1."; "Keyed = SHA1.";
= } }
enum = meticulous-keyed-sha1 { enum = meticulous-keyed-sha1 {
value = 5; value 5;
= description = description
= "Meticulous Keyed SHA1."; = "Meticulous Keyed SHA1.";
= } }
} = }
= description description
"BFD = authentication types as defined in RFC 5880. = Values are "BFD = authentication type as defined in RFC = 5880. Values are
= maintained in the 'BFD Authentication Types' IANA registry. = maintained in the 'BFD Authentication = Types' IANA registry.
Range = is 0 to 255."; Range is 0 to = 255.";
= reference reference
"RFC = 5880: Bidirectional Forwarding Detection (BFD)"; "RFC 5880: Bidirectional Forwarding Detection = (BFD)";
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.13. BFD Types YANG Module 2.12. BFD Types YANG = Module
=
This YANG = module imports typedefs from [RFC6991] and [RFC8177]. It = This YANG module imports typedefs from = [RFC6991] and [RFC8177]. It
also imports = definitions from [RFC5880], [RFC5881], [RFC5883], also imports definitions from [RFC5880], [RFC5881], = [RFC5883],
[RFC5884], and = [RFC7130], as well as the "control-plane-protocol" [RFC5884], and [RFC7130], as well as the = "control-plane-protocol"
identity from = [RFC8349]. identity from = [RFC8349].
=
<CODE = BEGINS> file "ietf-bfd-types@2019-11-19.yang" = <CODE BEGINS> file "ietf-bfd-types@2021-04-08.yang"
module = ietf-bfd-types { module = ietf-bfd-types {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-types"; namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-types";
prefix = "bfd-types"; prefix = "bfd-types";
=
import = iana-bfd-types { import = iana-bfd-types {
prefix = "iana-bfd-types"; prefix = "iana-bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 1280 =C2=B6 = skipping to change at = line 1144 =C2=B6
= <mailto:vero.zheng@huawei.com> = <mailto:vero.zheng@huawei.com>
=
Editor: = Mahesh Jethanandani Editor: = Mahesh Jethanandani
= <mailto:mjethanandani@gmail.com>"; = <mailto:mjethanandani@gmail.com>";
=
= description description
"This = module contains a collection of BFD-specific YANG data type = "This module contains a collection of = BFD-specific YANG data type
= definitions, as per RFC 5880, and also groupings that are = common definitions, as per RFC = 5880, and also groupings that are common
to other = BFD YANG modules. to other BFD = YANG modules.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 5880: = Bidirectional Forwarding Detection (BFD) "RFC 5880: Bidirectional Forwarding Detection = (BFD)
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2019-11-19 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* Feature = definitions * Feature = definitions
*/ = */
=
skipping = to change at = line 1483 =C2=B6 = skipping to change at = line 1347 =C2=B6
= if-feature authentication; = if-feature authentication;
= presence presence
= "Enables BFD authentication (see Section 6.7 of RFC 5880)."; = "Enables BFD authentication (see = Section 6.7 of RFC 5880).";
= description = description
= "Parameters for BFD authentication."; = "Parameters for BFD authentication.";
= reference reference
"RFC = 5880: Bidirectional Forwarding Detection (BFD), "RFC 5880: Bidirectional Forwarding Detection = (BFD),
= Section 6.7"; Section = 6.7";
=
leaf = key-chain { leaf key-chain = {
type = kc:key-chain-ref; type key-chain:key-chain-ref;
= description = description
= "Name of the 'key-chain' as per RFC 8177."; "Name of the 'key-chain' as per RFC = 8177.";
= } }
=
leaf = meticulous { leaf meticulous = {
type = boolean; type = boolean;
= description = description
= "Enables a meticulous mode as per Section 6.7 of "Enables a meticulous mode as per Section = 6.7 of
RFC = 5880."; RFC = 5880.";
= } }
=
skipping = to change at = line 1903 =C2=B6 = skipping to change at = line 1767 =C2=B6
type = identityref { type = identityref {
base = path-type; base = path-type;
= } }
= description = description
"BFD = path type."; "BFD path = type.";
} = }
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.14. BFD Top-Level YANG Module 2.13. BFD Top-Level YANG = Module
=
This YANG = module imports and augments "/routing/control-plane- This YANG module imports and augments = "/routing/control-plane-
= protocols/control-plane-protocol" from [RFC8349]. It also = references = protocols/control-plane-protocol" from [RFC8349]. It also = references
= [RFC5880]. [RFC5880].
=
<CODE = BEGINS> file "ietf-bfd@2018-08-01.yang" = <CODE BEGINS> file "ietf-bfd@2021-04-08.yang"
module = ietf-bfd { module ietf-bfd = {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd"; = namespace "urn:ietf:params:xml:ns:yang:ietf-bfd";
prefix = "bfd"; prefix "bfd";
=
import = ietf-bfd-types { import = ietf-bfd-types {
prefix = "bfd-types"; prefix = "bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 1967 =C2=B6 = skipping to change at = line 1831 =C2=B6
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 5880: = Bidirectional Forwarding Detection (BFD) "RFC 5880: Bidirectional Forwarding Detection = (BFD)
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
augment = "/rt:routing/rt:control-plane-protocols/" augment = "/rt:routing/rt:control-plane-protocols/"
+ = "rt:control-plane-protocol" { = + "rt:control-plane-protocol" {
when = "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" { when "derived-from-or-self(rt:type, = 'bfd-types:bfdv1')" {
=
skipping = to change at = line 1995 =C2=B6 = skipping to change at = line 1859 =C2=B6
container = bfd { container bfd {
= description = description
"BFD = top-level container."; "BFD = top-level container.";
=
uses = bfd-types:session-statistics-summary; = uses bfd-types:session-statistics-summary;
} = }
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.15. BFD IP Single-Hop YANG Module = 2.14. BFD IP = Single-Hop YANG Module
=
This YANG = module imports "interface-ref" from [RFC8343] and typedefs = This YANG module imports "interface-ref" = from [RFC8343] and typedefs
from = [RFC6991]. It also imports and augments "/routing/control- = from [RFC6991]. It also imports and = augments "/routing/control-
= plane-protocols/control-plane-protocol" from [RFC8349], and it = plane-protocols/control-plane-protocol" from = [RFC8349], and it
references = [RFC5881]. references = [RFC5881].
=
<CODE = BEGINS> file "ietf-bfd-ip-sh@2018-08-01.yang" = <CODE BEGINS> file "ietf-bfd-ip-sh@2021-04-08.yang"
module = ietf-bfd-ip-sh { module = ietf-bfd-ip-sh {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"; namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh";
prefix = "bfd-ip-sh"; prefix = "bfd-ip-sh";
=
import = ietf-bfd-types { import = ietf-bfd-types {
prefix = "bfd-types"; prefix = "bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 2061 =C2=B6 = skipping to change at = line 1925 =C2=B6
Editor: = Lianshu Zheng Editor: = Lianshu Zheng
= <mailto:vero.zheng@huawei.com> = <mailto:vero.zheng@huawei.com>
=
Editor: = Mahesh Jethanandani Editor: = Mahesh Jethanandani
= <mailto:mjethanandani@gmail.com>"; = <mailto:mjethanandani@gmail.com>";
=
= description description
"This = module contains the YANG definition for BFD IP single-hop = "This module contains the YANG = definition for BFD IP single-hop
as per = RFC 5881. as per RFC = 5881.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 5881: = Bidirectional Forwarding Detection (BFD) "RFC 5881: Bidirectional Forwarding Detection = (BFD)
for IPv4 = and IPv6 (Single Hop) for IPv4 = and IPv6 (Single Hop)
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* = Augments * Augments
*/ = */
=
skipping = to change at = line 2170 =C2=B6 = skipping to change at = line 2034 =C2=B6
=
leaf = echo-enabled { leaf = echo-enabled {
type = boolean; type = boolean;
= description = description
= "Indicates whether Echo was enabled for BFD."; "Indicates whether Echo was enabled for = BFD.";
} = }
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.16. BFD IP Multihop YANG Module = 2.15. BFD IP = Multihop YANG Module
=
This YANG = module imports typedefs from [RFC6991]. It also imports = This YANG module imports typedefs from = [RFC6991]. It also imports
and augments = "/routing/control-plane-protocols/control-plane- and augments = "/routing/control-plane-protocols/control-plane-
protocol" from = [RFC8349], and it references [RFC5883]. = protocol" from [RFC8349], and it references [RFC5883].
=
<CODE = BEGINS> file "ietf-bfd-ip-mh@2018-08-01.yang" = <CODE BEGINS> file "ietf-bfd-ip-mh@2021-04-08.yang"
module = ietf-bfd-ip-mh { module = ietf-bfd-ip-mh {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh"; namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh";
prefix = "bfd-ip-mh"; prefix = "bfd-ip-mh";
=
import = ietf-bfd-types { import = ietf-bfd-types {
prefix = "bfd-types"; prefix = "bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 2229 =C2=B6 = skipping to change at = line 2093 =C2=B6
Editor: = Lianshu Zheng Editor: = Lianshu Zheng
= <mailto:vero.zheng@huawei.com> = <mailto:vero.zheng@huawei.com>
=
Editor: = Mahesh Jethanandani Editor: = Mahesh Jethanandani
= <mailto:mjethanandani@gmail.com>"; = <mailto:mjethanandani@gmail.com>";
=
= description description
"This = module contains the YANG definition for BFD IP multihop = "This module contains the YANG = definition for BFD IP multihop
as per = RFC 5883. as per RFC = 5883.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 5883: = Bidirectional Forwarding Detection (BFD) for "RFC 5883: Bidirectional Forwarding Detection = (BFD) for
Multihop = Paths Multihop Paths
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* = Augments * Augments
*/ = */
=
skipping = to change at = line 2332 =C2=B6 = skipping to change at = line 2196 =C2=B6
= description description
= "Notification for BFD multihop session state change. An = "Notification for BFD multihop session = state change. An
= implementation may rate-limit notifications, e.g., when a = implementation may rate-limit = notifications, e.g., when a
session = is continuously changing state."; = session is continuously changing state.";
=
uses = bfd-types:notification-parms; = uses bfd-types:notification-parms;
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.17. BFD-over-LAG YANG Module 2.16. BFD-over-LAG YANG = Module
=
This YANG = module imports "interface-ref" from [RFC8343] and typedefs = This YANG module imports "interface-ref" = from [RFC8343] and typedefs
from = [RFC6991]. It also imports and augments "/routing/control- = from [RFC6991]. It also imports and = augments "/routing/control-
= plane-protocols/control-plane-protocol" from [RFC8349]. = plane-protocols/control-plane-protocol" from = [RFC8349].
Additionally, = it references [RFC7130]. = Additionally, it references [RFC7130].
=
<CODE = BEGINS> file "ietf-bfd-lag@2018-08-01.yang" = <CODE BEGINS> file "ietf-bfd-lag@2021-04-08.yang"
module = ietf-bfd-lag { module ietf-bfd-lag = {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-lag"; namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-lag";
prefix = "bfd-lag"; prefix = "bfd-lag";
=
import = ietf-bfd-types { import = ietf-bfd-types {
prefix = "bfd-types"; prefix = "bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 2398 =C2=B6 = skipping to change at = line 2262 =C2=B6
Editor: = Lianshu Zheng Editor: = Lianshu Zheng
= <mailto:vero.zheng@huawei.com> = <mailto:vero.zheng@huawei.com>
=
Editor: = Mahesh Jethanandani Editor: = Mahesh Jethanandani
= <mailto:mjethanandani@gmail.com>"; = <mailto:mjethanandani@gmail.com>";
=
= description description
"This = module contains the YANG definition for BFD-over-LAG "This module contains the YANG definition for = BFD-over-LAG
= interfaces as per RFC 7130. = interfaces as per RFC 7130.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 7130: = Bidirectional Forwarding Detection (BFD) on "RFC 7130: Bidirectional Forwarding Detection = (BFD) on
Link = Aggregation Group (LAG) Interfaces = Link Aggregation Group (LAG) Interfaces
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* = Augments * Augments
*/ = */
=
skipping = to change at = line 2544 =C2=B6 = skipping to change at = line 2408 =C2=B6
=
leaf = member-link { leaf member-link = {
type = if:interface-ref; type = if:interface-ref;
= description = description
= "Member link on which BFD is running."; = "Member link on which BFD is running.";
} = }
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.18. BFD-over-MPLS YANG Module 2.17. BFD-over-MPLS YANG = Module
=
This YANG = module imports typedefs from [RFC6991]. It also imports = This YANG module imports typedefs from = [RFC6991]. It also imports
and augments = "/routing/control-plane-protocols/control-plane- and augments = "/routing/control-plane-protocols/control-plane-
protocol" from = [RFC8349]. Additionally, it references [RFC5586] and protocol" from [RFC8349]. Additionally, it = references [RFC5586] and
= [RFC5884]. [RFC5884].
=
<CODE = BEGINS> file "ietf-bfd-mpls@2018-08-01.yang" = <CODE BEGINS> file "ietf-bfd-mpls@2021-04-08.yang"
module = ietf-bfd-mpls { module = ietf-bfd-mpls {
=
yang-version = 1.1; yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls"; namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls";
prefix = "bfd-mpls"; prefix = "bfd-mpls";
=
import = ietf-bfd-types { import = ietf-bfd-types {
prefix = "bfd-types"; prefix = "bfd-types";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
=
skipping = to change at = line 2604 =C2=B6 = skipping to change at = line 2468 =C2=B6
Editor: = Lianshu Zheng Editor: = Lianshu Zheng
= <mailto:vero.zheng@huawei.com> = <mailto:vero.zheng@huawei.com>
=
Editor: = Mahesh Jethanandani Editor: = Mahesh Jethanandani
= <mailto:mjethanandani@gmail.com>"; = <mailto:mjethanandani@gmail.com>";
=
= description description
"This = module contains the YANG definition for BFD parameters for = "This module contains the YANG = definition for BFD parameters for
MPLS LSPs = as per RFC 5884. MPLS LSPs as = per RFC 5884.
=
= Copyright (c) 2020 IETF Trust and the = persons identified as = Copyright (c) 2021 IETF Trust and the = persons identified as
authors = of the code. All rights reserved. = authors of the code. All rights reserved.
=
= Redistribution and use in source and binary forms, with or = Redistribution and use in source and = binary forms, with or
without = modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, = and subject to
the = license terms contained in, the Simplified BSD License set = the license terms contained in, the = Simplified BSD License set
forth in = Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating = to IETF Documents Relating to = IETF Documents
= (https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
=
This = version of this YANG module is part of RFC 0000; see the = This version of this YANG module is = part of RFC 0000; see the
RFC = itself for full legal notices."; = RFC itself for full legal notices.";
=
= reference reference
"RFC 5884: = Bidirectional Forwarding Detection (BFD) "RFC 5884: Bidirectional Forwarding Detection = (BFD)
for MPLS = Label Switched Paths (LSPs) = for MPLS Label Switched Paths (LSPs)
RFC 0000: = YANG Data Model for Bidirectional Forwarding RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection = (BFD)"; Detection = (BFD)";
=
revision = 2018-08-01 { revision 2021-04-08 = {
= description description
"Initial = revision."; "Initial = revision.";
= reference reference
"RFC = 0000: YANG Data Model for Bidirectional Forwarding "RFC 0000: YANG Data Model for Bidirectional = Forwarding
= Detection (BFD)"; Detection = (BFD)";
} = }
=
/* = /*
* Identity = definitions * Identity = definitions
*/ = */
=
skipping = to change at = line 2756 =C2=B6 = skipping to change at = line 2620 =C2=B6
leaf = mpls-dest-address { leaf = mpls-dest-address {
type = inet:ip-address; type = inet:ip-address;
= description = description
= "Destination address as per RFC 5884. = "Destination address as per RFC 5884.
= Needed if IP encapsulation is used."; = Needed if IP encapsulation is used.";
} = }
} = }
} = }
<CODE = ENDS> <CODE ENDS>
=
2.19. BFD-over-MPLS-TE YANG Module =
This YANG module imports and augments = "/routing/control-plane-
protocols/control-plane-protocol" from [RFC8349]. = It also imports
and augments "/te/tunnels/tunnel" from [RFCYYY2], = and it references
[RFC5884].
<CODE BEGINS> file = "ietf-bfd-mpls-te@2018-08-01.yang"
module ietf-bfd-mpls-te {
yang-version 1.1;
namespace = "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te";
prefix "bfd-mpls-te";
import ietf-bfd-types {
prefix "bfd-types";
reference
"RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection (BFD)";
}
import ietf-bfd {
prefix "bfd";
reference
"RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection (BFD)";
}
import ietf-bfd-mpls {
prefix "bfd-mpls";
reference
"RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection (BFD)";
}
import ietf-te {
prefix "te";
reference
"RFC YYY2: A YANG Data Model for Traffic = Engineering Tunnels,
Label Switched Paths, and = Interfaces";
}
import ietf-routing {
prefix "rt";
reference
"RFC 8349: A YANG Data Model for Routing = Management
(NMDA Version)";
}
organization "IETF BFD Working = Group";
contact
"WG Web: = <https://datatracker.ietf.org/wg/bfd/>
WG List: = <mailto:rtg-bfd@ietf.org>
Editor: Reshad Rahman =
= <mailto:reshad@yahoo.com>
Editor: Lianshu Zheng =
= <mailto:vero.zheng@huawei.com>
Editor: Mahesh Jethanandani =
= <mailto:mjethanandani@gmail.com>";
description
"This module contains the YANG definition for = BFD parameters for
MPLS Traffic Engineering as per RFC = 5884.
Copyright (c) 2020 IETF Trust and the persons = identified as
authors of the code. All rights = reserved.
Redistribution and use in source and binary = forms, with or
without modification, is permitted pursuant to, = and subject to
the license terms contained in, the Simplified = BSD License set
forth in Section 4.c of the IETF Trust's Legal = Provisions
Relating to IETF Documents =
= (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC = 0000; see the
RFC itself for full legal = notices.";
reference
"RFC 5884: Bidirectional Forwarding Detection = (BFD)
for MPLS Label Switched Paths = (LSPs)
RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection (BFD)";
revision 2018-08-01 {
description
"Initial revision.";
reference
"RFC 0000: YANG Data Model for Bidirectional = Forwarding
Detection (BFD)";
}
/*
* Augments
*/
augment = "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd" = {
description
"BFD augmentation for = MPLS-TE.";
container mpls-te {
description
"BFD MPLS-TE top-level = container.";
container egress {
description
"Egress configuration."; =
uses = bfd-types:client-cfg-parms;
uses bfd-types:auth-parms; =
}
uses = bfd-types:session-statistics-summary;
}
}
augment "/te:te/te:tunnels/te:tunnel" = {
description
"BFD configuration on the MPLS-TE = tunnel.";
uses bfd-types:common-cfg-parms; =
uses bfd-mpls:encap-cfg; =
}
augment "/te:te/te:lsps/te:lsp" { =
when "/te:te/te:lsps/te:lsp/te:origin-type !=3D = 'transit'" {
description
"BFD information not needed at transit = points.";
}
description
"BFD state information on the MPLS-TE = LSP.";
uses bfd-types:all-session; =
uses bfd-mpls:mpls-dest-address; =
}
/*
* Notifications
*/
notification mpls-te-notification = {
description
"Notification for BFD-over-MPLS-TE session = state change.
An implementation may rate-limit = notifications, e.g., when a
session is continuously changing = state.";
uses = bfd-types:notification-parms;
uses bfd-mpls:mpls-dest-address; =
leaf tunnel-name {
type string;
description
"MPLS-TE tunnel on which BFD was = running.";
}
}
}
<CODE ENDS>
= =
3. Data Model = Examples 3. Data Model = Examples
=
This section = presents some simple and illustrative examples of how to = This section presents some simple and = illustrative examples of how to
configure = BFD. configure BFD.
=
The examples = are represented in XML [W3C.REC-xml-20081126]. The examples are represented in XML = [W3C.REC-xml-20081126].
=
3.1. IP = Single-Hop 3.1. IP Single-Hop
=
The following = is an example configuration for a BFD IP single-hop The following is an example configuration for a BFD = IP single-hop
=
skipping = to change at = line 3170 =C2=B6 = skipping to change at = line 2871 =C2=B6
=
= /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/= = /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/
= egress: egress:
Data nodes = "local-multiplier", "desired-min-tx-interval", Data nodes "local-multiplier", = "desired-min-tx-interval",
= "required-min-rx-interval", and "min-interval" all impact the = BFD- "required-min-rx-interval", = and "min-interval" all impact the BFD-
= over-MPLS-LSPs sessions for which this device is an MPLS LSP = over-MPLS-LSPs sessions for which this = device is an MPLS LSP
egress = node. Authentication data nodes "key-chain" and egress node. Authentication data nodes = "key-chain" and
= "meticulous" impact the security of the BFD-over-MPLS-LSPs = "meticulous" impact the security of the = BFD-over-MPLS-LSPs
sessions = for which this device is an MPLS LSP egress node. sessions for which this device is an MPLS LSP = egress node.
=
/te/tunnels/tunnel:
Data nodes "local-multiplier", = "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" = all impact the BFD
session over the MPLS-TE tunnel. Authentication = data nodes "key-
chain" and "meticulous" impact the security of = the BFD session
over the MPLS-TE tunnel.
= /routing/control-plane-protocols/control-plane-protocol/bfd/mpls-
te/egress:
Data nodes "local-multiplier", = "desired-min-tx-interval",
"required-min-rx-interval", and "min-interval" = all impact the BFD-
over-MPLS-TE sessions for which this device is an = MPLS-TE egress
node. Authentication data nodes "key-chain" and = "meticulous"
impact the security of the BFD-over-MPLS-TE = sessions for which
this device is an MPLS-TE egress = node.
= =
The YANG = modules have writable data nodes that can be used for the = The YANG modules have writable data nodes = that can be used for the
creation of = BFD sessions and the modification of BFD session creation of BFD sessions and the modification of BFD = session
parameters. = The system should "police" the creation of BFD sessions = parameters. The system should "police" the = creation of BFD sessions
to prevent new = sessions from causing existing BFD sessions to fail. to prevent new sessions from causing existing BFD = sessions to fail.
In the case of = BFD session modification, the BFD protocol has In the case of BFD session modification, the BFD = protocol has
mechanisms in = place that allow for in-service modification. mechanisms in place that allow for in-service = modification.
=
When BFD = clients are used to modify BFD configuration (as described = When BFD clients are used to modify BFD = configuration (as described
in Section = 2.1), the BFD clients need to be included in an analysis = in Section 2.1), the BFD clients need to be = included in an analysis
of the = security properties of the system that uses BFD (e.g., when = of the security properties of the system = that uses BFD (e.g., when
=
skipping = to change at = line 3281 =C2=B6 = skipping to change at = line 2966 =C2=B6
state. The = counters include BFD sessions for which the user does state. The counters include BFD sessions for = which the user does
not have = read access. not have read = access.
=
= /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/= = /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/
= session-groups/session-group/sessions: = session-groups/session-group/sessions:
Access to = data nodes "local-discriminator" and "remote- Access to data nodes "local-discriminator" and = "remote-
= discriminator" (combined with the data nodes in the session = discriminator" (combined with the data = nodes in the session
group's = authentication container) provides the ability to spoof = group's authentication container) = provides the ability to spoof
= BFD-over-MPLS-LSPs packets. = BFD-over-MPLS-LSPs packets.
=
/routing/control-plane-protocols/control-plane-protocol/b= fd/mpls-
te/summary:
Access to this information discloses the number = of BFD sessions
over MPLS-TE that are in the "up", "down", or = "admin-down" state.
The counters include BFD sessions for which the = user does not have
read access.
/te/lsps/lsp:
Access to data nodes "local-discriminator" and = "remote-
discriminator" (combined with the data nodes in = the tunnel's
authentication container) provides the ability to = spoof BFD-over-
MPLS-TE packets.
= =
5. IANA = Considerations 5. IANA = Considerations
=
This document = registers the following namespace URIs in the "IETF XML = This document registers the following = namespace URIs in the "IETF XML
Registry" = [RFC3688]: Registry" = [RFC3688]:
=
URI: = urn:ietf:params:xml:ns:yang:iana-bfd-types URI: = urn:ietf:params:xml:ns:yang:iana-bfd-types
Registrant = Contact: The IESG. Registrant = Contact: The IESG.
XML: N/A; the = requested URI is an XML namespace. = XML: N/A; the requested URI is an XML namespace.
=
URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-types URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-types
=
skipping = to change at = line 3327 =C2=B6 = skipping to change at = line 2999 =C2=B6
XML: N/A; the = requested URI is an XML namespace. = XML: N/A; the requested URI is an XML namespace.
=
URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-lag URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-lag
Registrant = Contact: The IESG. Registrant = Contact: The IESG.
XML: N/A; the = requested URI is an XML namespace. = XML: N/A; the requested URI is an XML namespace.
=
URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls
Registrant = Contact: The IESG. Registrant = Contact: The IESG.
XML: N/A; the = requested URI is an XML namespace. = XML: N/A; the requested URI is an XML namespace.
=
URI: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te
Registrant Contact: The IESG. =
XML: N/A; the requested URI is an XML = namespace.
= =
This document = registers the following YANG modules in the "YANG This document registers the following YANG modules in = the "YANG
Module Names" = registry [RFC6020]: Module Names" = registry [RFC6020]:
=
Name: = iana-bfd-types Name: = iana-bfd-types
Namespace: = urn:ietf:params:xml:ns:yang:iana-bfd-types Namespace: = urn:ietf:params:xml:ns:yang:iana-bfd-types
Prefix: = iana-bfd-types Prefix: = iana-bfd-types
Reference: = RFC 0000 Reference: RFC = 0000
=
Name: = ietf-bfd-types Name: = ietf-bfd-types
Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-types Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-types
=
skipping = to change at = line 3369 =C2=B6 = skipping to change at = line 3037 =C2=B6
Name: = ietf-bfd-lag Name: = ietf-bfd-lag
Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-lag Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-lag
Prefix: = bfd-lag Prefix: bfd-lag
Reference: = RFC 0000 Reference: RFC = 0000
=
Name: = ietf-bfd-mpls Name: = ietf-bfd-mpls
Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls
Prefix: = bfd-mpls Prefix: bfd-mpls
Reference: = RFC 0000 Reference: RFC = 0000
=
Name: ietf-bfd-mpls-te
Namespace: = urn:ietf:params:xml:ns:yang:ietf-bfd-mpls-te
Prefix: bfd-mpls-te
Reference: RFC 0000
= =
5.1. = IANA-Maintained "iana-bfd-types" Module 5.1. IANA-Maintained "iana-bfd-types" Module
=
This document = defines the initial version of the IANA-maintained This document defines the initial version of the = IANA-maintained
= "iana-bfd-types" YANG module. = "iana-bfd-types" YANG module.
=
The = "iana-bfd-types" YANG module mirrors the "BFD Diagnostic Codes" = The "iana-bfd-types" YANG module mirrors the = "BFD Diagnostic Codes"
and "BFD = Authentication Types" registries at = and "BFD Authentication Types" registries at
= <https://www.iana.org/assignments/bfd-parameters/>. Whenever = these = <https://www.iana.org/assignments/bfd-parameters/>. Whenever = these
registries = change, IANA must update the "iana-bfd-types" YANG module. = registries change, IANA must update the = "iana-bfd-types" YANG module.
=
=
skipping = to change at = line 3485 =C2=B6 = skipping to change at = line 3148 =C2=B6
=
[RFC8349] = Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for = [RFC8349] Lhotka, L., Lindem, A., and Y. = Qu, "A YANG Data Model for
= Routing Management (NMDA Version)", RFC 8349, Routing Management (NMDA Version)", RFC = 8349,
DOI = 10.17487/RFC8349, March 2018, = DOI 10.17487/RFC8349, March 2018,
= <https://www.rfc-editor.org/info/rfc8349>. = <https://www.rfc-editor.org/info/rfc8349>.
=
[RFC8446] = Rescorla, E., "The Transport Layer Security (TLS) Protocol = [RFC8446] Rescorla, E., "The Transport = Layer Security (TLS) Protocol
= Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, = Version 1.3", RFC 8446, DOI = 10.17487/RFC8446, August 2018,
= <https://www.rfc-editor.org/info/rfc8446>. = <https://www.rfc-editor.org/info/rfc8446>.
=
[RFCYYY1] Saad, T., Raza, K., Gandhi, R., Liu, = X., and V. Beeram, "A [RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, = X., and V. Beeram, "A
= YANG Data Model for MPLS Base", RFC YYY1, = YANG Data Model for MPLS Base", RFC 8960,
= DOI 10.17487/RFCYYY1, November = 2020, DOI 10.17487/RFC8960, November 2020,
= <https://www.rfc-editor.org/rfc/rfcYYY1>. <https://www.rfc-editor.org/rfc/rfc8960>.
[RFCYYY2] Saad, T., Gandhi, R., Liu, X., Beeram, = V., and I. Bryskin,
"A YANG Data Model for Traffic = Engineering Tunnels, Label
Switched Paths, and Interfaces", RFC = YYY2,
DOI 10.17487/RFCYYY2, November = 2020,
= <https://www.rfc-editor.org/rfc/rfcYYY2>.
=
= [W3C.REC-xml-20081126] = [W3C.REC-xml-20081126]
= Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and = Bray, T., Paoli, J., = Sperberg-McQueen, M., Maler, E., and
F. = Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language = (XML) 1.0 (Fifth
= Edition)", World Wide Web Consortium Recommendation REC- = Edition)", World Wide Web = Consortium Recommendation REC-
= xml-20081126, November 2008, = xml-20081126, November 2008,
= <https://www.w3.org/TR/2008/REC-xml-20081126>. = <https://www.w3.org/TR/2008/REC-xml-20081126>.
=
6.2. Informative = References 6.2. Informative = References
=
=
skipping = to change at = line 3668 =C2=B6 = skipping to change at = line 3325 =C2=B6
"BFD = Echo function container."; = "BFD Echo function container.";
=
uses = echo-cfg-parms; uses = echo-cfg-parms;
} = }
} = }
} = }
=
Acknowledgments Acknowledgments
=
We would like = to thank Nobo Akiya and Jeff Haas for their We would like to thank Nobo Akiya and Jeff Haas for = their
= encouragement on this work. We would also like to thank Rakesh = encouragement on this work. We would also like to thank Tom Petch
Gandhi and Tarek Saad for their help on the MPLS-TE = model. We would for his comments on the draft. We would also like to thank Acee
also like to = thank Acee Lindem for his guidance. Thanks also to Lindem for his guidance. Thanks also to Juergen = Schoenwaelder, who
Juergen = Schoenwaelder, who was instrumental in improving the YANG = was instrumental in improving the YANG = modules.
= modules.
=
Authors' = Addresses Authors' Addresses
=
Reshad Rahman = (editor) Reshad Rahman = (editor)
= Canada Canada
=
Email: = reshad@yahoo.com Email: = reshad@yahoo.com
=
Lianshu Zheng = (editor) Lianshu Zheng = (editor)
Huawei = Technologies Huawei = Technologies
 End of changes. 62 change blocks. 
418 lines changed or = deleted 74 lines changed or = added

This = html diff was produced by rfcdiff 1.48. The latest version is available = from http://tools.ietf.org/to= ols/rfcdiff/
=20 =20 = --Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
--Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C Content-Disposition: attachment; filename=draft-ietf-bfd-yang-18.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-bfd-yang-18.txt" Content-Transfer-Encoding: 7bit Internet Engineering Task Force (IETF) R. Rahman, Ed. Request for Comments: 0000 Category: Standards Track L. Zheng, Ed. ISSN: 2070-1721 Huawei Technologies M. Jethanandani, Ed. Xoriant Corporation S. Pallagatti RtBrick G. Mirsky ZTE Corporation April 2021 YANG Data Model for Bidirectional Forwarding Detection (BFD) Abstract This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) (RFC 8342). Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc0000. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Tree Diagrams 2. Design of the Data Model 2.1. Design of the Configuration Model 2.1.1. Common BFD Configuration Parameters 2.1.2. Single-Hop IP 2.1.3. Multihop IP 2.1.4. MPLS Label Switched Paths 2.1.5. Link Aggregation Groups 2.2. Design of the Operational State Model 2.3. Notifications 2.4. RPC Operations 2.5. BFD Top-Level Hierarchy 2.6. BFD IP Single-Hop Hierarchy 2.7. BFD IP Multihop Hierarchy 2.8. BFD-over-LAG Hierarchy 2.9. BFD-over-MPLS-LSPs Hierarchy 2.10. Interaction with Other YANG Modules 2.10.1. "ietf-interfaces" Module 2.10.2. "ietf-ip" Module 2.10.3. "ietf-mpls" Module 2.11. IANA BFD YANG Module 2.12. BFD Types YANG Module 2.13. BFD Top-Level YANG Module 2.14. BFD IP Single-Hop YANG Module 2.15. BFD IP Multihop YANG Module 2.16. BFD-over-LAG YANG Module 2.17. BFD-over-MPLS YANG Module 3. Data Model Examples 3.1. IP Single-Hop 3.2. IP Multihop 3.3. LAG 3.4. MPLS 4. Security Considerations 5. IANA Considerations 5.1. IANA-Maintained "iana-bfd-types" Module 6. References 6.1. Normative References 6.2. Informative References Appendix A. Echo Function Configuration Example A.1. Example YANG Module for BFD Echo Function Configuration Acknowledgments Authors' Addresses 1. Introduction This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD) [RFC5880]. BFD is a network protocol that is used for liveness detection of arbitrary paths between systems. Some examples of different types of paths over which we have BFD are as follows: 1. Two systems directly connected via IP. This is known as BFD over single-hop IP, a.k.a. BFD for IPv4 and IPv6 [RFC5881]. 2. Two systems connected via multiple hops as described in "Bidirectional Forwarding Detection (BFD) for Multihop Paths" [RFC5883]. 3. Two systems connected via MPLS Label Switched Paths (LSPs) as described in "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)" [RFC5884]. 4. Two systems connected via a Link Aggregation Group (LAG) interface as described in "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" [RFC7130]. 5. Two systems connected via pseudowires (PWs). This is known as Virtual Circuit Connectivity Verification (VCCV), as described in "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)" [RFC5885]. This scenario is not addressed in this document. BFD typically does not operate on its own. Various control protocols, also known as BFD clients, use the services provided by BFD for their own operation, as described in "Generic Application of Bidirectional Forwarding Detection (BFD)" [RFC5882]. The obvious candidates that use BFD are those that do not have "hellos" to detect failures, e.g., static routes, and routing protocols whose "hellos" do not support sub-second failure detection, e.g., OSPF and IS-IS. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) [RFC8342]. This means that the data models do not have separate top-level or sibling containers for configuration data and operational state data. 1.1. Tree Diagrams This document uses the graphical representation of data models, as defined in [RFC8340]. 2. Design of the Data Model Since BFD is used for liveness detection of various forwarding paths, there is no uniform key to identify a BFD session, and so the BFD data model is split into multiple YANG modules where each module corresponds to one type of forwarding path. For example, BFD for IP single-hop is in one YANG module, and BFD for MPLS is in another YANG module. The main difference between these modules is how a BFD session is uniquely identified, i.e., the key for the list containing the BFD sessions for that forwarding path. To avoid duplication of BFD definitions, we have common types and groupings that are used by all the modules. A new control-plane protocol, "bfdv1", is defined, and a "bfd" container is created under "control-plane-protocol" as specified in "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349]. This new "bfd" container is augmented by the following YANG modules for their respective specific information: 1. The "ietf-bfd-ip-sh" module (Section 2.14) augments "/routing/ control-plane-protocols/control-plane-protocol/bfd/" with the "ip-sh" container for BFD sessions over IP single-hop. 2. The "ietf-bfd-ip-mh" module (Section 2.15) augments "/routing/ control-plane-protocols/control-plane-protocol/bfd/" with the "ip-mh" container for BFD sessions over IP multihop. 3. The "ietf-bfd-lag" module (Section 2.16) augments "/routing/ control-plane-protocols/control-plane-protocol/bfd/" with the "lag" container for BFD sessions over a LAG. 4. The "ietf-bfd-mpls" module (Section 2.17) augments "/routing/ control-plane-protocols/control-plane-protocol/bfd/" with the "mpls" container for BFD-over-MPLS LSPs. BFD can operate in the following contexts: 1. At the network device level. 2. In logical network elements (LNEs) as described in "YANG Model for Logical Network Elements" [RFC8530]. 3. In network instances as described in "YANG Data Model for Network Instances" [RFC8529]. When used at the network device level, the BFD YANG data model is used "as is". When the BFD YANG data model is used in an LNE or network instance, the BFD YANG data model augments the mounted routing model for the LNE or network instance. 2.1. Design of the Configuration Model The configuration model consists mainly of the parameters specified in BFD [RFC5880] -- for example, desired minimum transmit interval, required minimum receive interval, detection multiplier. BFD clients are applications that use BFD for fast detection of failures. Some implementations have BFD session configuration under the BFD clients -- for example, BFD session configuration under routing applications such as OSPF, IS-IS, or BGP. Other implementations have BFD session configuration centralized under BFD, i.e., outside the multiple BFD clients. The main BFD parameters of interest to a BFD client are those related to the multiplier and interval(s), since those parameters impact the convergence time of the BFD clients when a failure occurs. Other parameters, such as BFD authentication, are not specific to the requirements of the BFD client. Configuration of BFD for all clients should be centralized. However, this is a problem for BFD clients that auto-discover their peers. For example, IGPs do not have the peer address configured; instead, the IGP is enabled on an interface, and the IGP peers are auto-discovered. So, for an operator to configure BFD to an IGP peer, the operator would first have to determine the peer addresses. And when a new peer is discovered, BFD configuration would need to be added. To avoid this issue, we define the grouping "client-cfg-parms" in Section 2.12 for BFD clients to configure BFD: this allows BFD clients, such as the IGPs, to have configuration (multiplier and intervals) for the BFD sessions they need. For example, when a new IGP peer is discovered, the IGP would create a BFD session to the newly discovered peer; similarly, when an IGP peer goes away, the IGP would remove the BFD session to that peer. The mechanism for how the BFD sessions are created and removed by the BFD clients is outside the scope of this document, but this would typically be done by using an API implemented by the BFD module on the system. In the case of BFD clients that create BFD sessions via their own configuration, authentication parameters (if required) are still specified in BFD. 2.1.1. Common BFD Configuration Parameters The basic BFD configuration parameters are as follows: local-multiplier This is the detection time multiplier as defined in BFD [RFC5880]. desired-min-tx-interval This is the Desired Min TX Interval as defined in BFD [RFC5880]. required-min-rx-interval This is the Required Min RX Interval as defined in BFD [RFC5880]. Although BFD [RFC5880] allows for different values for transmit and receive intervals, some implementations allow users to specify just one interval that is used for both transmit and receive intervals, or separate values for transmit and receive intervals. The BFD YANG data model supports this: there is a choice between "min-interval", used for both transmit and receive intervals, and "desired-min-tx- interval" and "required-min-rx-interval". This is supported via the "base-cfg-parms" grouping (Section 2.12), which is used by the YANG modules for the various forwarding paths. For BFD authentication, we have the following: key-chain This is a reference to "key-chain" as defined in "YANG Data Model for Key Chains" [RFC8177]. The keys, cryptographic algorithms, key lifetime, etc. are all defined in the "key-chain" model. meticulous This enables a meticulous mode as per BFD [RFC5880]. 2.1.2. Single-Hop IP For single-hop IP, there is an augment of the "bfd" data node, as described in Section 2. The "ip-sh" node contains a list of IP single-hop sessions where each session is uniquely identified by the interface and destination address pair. We use the configuration parameters defined in Section 2.1.1. The "ip-sh" node also contains a list of interfaces and is used to specify authentication parameters for BFD sessions that are created by BFD clients. See Section 2.1. [RFC5880] and [RFC5881] do not specify whether the Echo function operates continuously or on demand. Therefore, the mechanism used to start and stop the Echo function is implementation specific and should be done by augmentation: 1. Configuration. This is suitable for an Echo function that operates continuously. An example is provided in Appendix A. 2. RPC. This is suitable for an Echo function that operates on demand. 2.1.3. Multihop IP For multihop IP, there is an augment of the "bfd" data node, as described in Section 2. Because of multiple paths, there could be multiple multihop IP sessions between a source and a destination address. We identify this set of sessions as a "session-group". The key for each "session-group" consists of the following: Source address Address belonging to the local system as per "Bidirectional Forwarding Detection (BFD) for Multihop Paths" [RFC5883]. Destination address Address belonging to the remote system as per [RFC5883]. We use the configuration parameters defined in Section 2.1.1. This document also provides the following parameters: tx-ttl TTL of outgoing BFD control packets. rx-ttl Minimum TTL of incoming BFD control packets. 2.1.4. MPLS Label Switched Paths Here, we address MPLS LSPs whose Forwarding Equivalence Class (FEC) [RFC3031] is an IP address. The "bfd" node (Section 2) is augmented with "mpls", which contains a list of sessions uniquely identified by an IP prefix. Because of multiple paths, there could be multiple MPLS sessions to an MPLS FEC. We identify this set of sessions as a "session-group". Since these LSPs are unidirectional, there is no LSP configuration on the egress node. The BFD parameters for the egress node are added under "mpls". 2.1.5. Link Aggregation Groups Per "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces" [RFC7130], configuring BFD on a LAG consists of having micro-BFD sessions on each LAG member link. Since the BFD parameters are an attribute of the LAG, they should be under the LAG. However, there is no LAG YANG data model that we can augment. So, a "lag" data node is added to the "bfd" node; see Section 2. The configuration is per LAG: we have a list of LAGs. The destination IP address of the micro-BFD sessions is configured per LAG and per address family (IPv4 and IPv6). 2.2. Design of the Operational State Model The operational state model contains both the overall statistics for the BFD sessions running on the device and the per-session operational information. The overall statistics for the BFD sessions consist of the number of BFD sessions, the number of BFD sessions that are up, etc. This information is available globally (i.e., for all BFD sessions) under the "bfd" node (Section 2) and also per type of forwarding path. For each BFD session, three main categories of operational state data are shown. 1. The first category includes fundamental information regarding a BFD session, such as the local discriminator, the remote discriminator, and the ability to support Demand mode. 2. The second category includes BFD "session-running" information, e.g., the remote BFD state and the diagnostic code received. Another example is the actual transmit interval between the control packets, which may be different from the configured desired minimum transmit interval. Similar examples include the actual receive interval between the control packets and the actual transmit interval between the Echo packets. 3. The third category contains the detailed statistics for the session, e.g., when the session transitioned up/down and how long it has been in that state. For some path types, there may be more than one session on the virtual path to the destination. For example, with IP multihop and MPLS LSPs, there could be multiple BFD sessions from the source to the same destination to test the various paths (ECMP) to the destination. This is represented by having multiple "sessions" under each "session-group". 2.3. Notifications This YANG data model defines notifications to inform end users of important events detected during the protocol operation. The local discriminator identifies the corresponding BFD session on the local system, and the remote discriminator identifies the BFD session on the remote system. Notifications also give more important details about BFD sessions, e.g., new state, time in previous state, network instance, and the reason that the BFD session state changed. The notifications are defined for each type of forwarding path but use groupings for common information. 2.4. RPC Operations None. 2.5. BFD Top-Level Hierarchy At the "bfd" node under "control-plane-protocol", there is no configuration data -- only operational state data. The operational state data consists of overall BFD session statistics, i.e., for BFD on all types of forwarding paths. module: ietf-bfd augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol: +--rw bfd +--ro summary +--ro number-of-sessions? yang:gauge32 +--ro number-of-sessions-up? yang:gauge32 +--ro number-of-sessions-down? yang:gauge32 +--ro number-of-sessions-admin-down? yang:gauge32 2.6. BFD IP Single-Hop Hierarchy An "ip-sh" node is added under the "bfd" node in "control-plane- protocol". The configuration data and operational state data for each BFD IP single-hop session are under this "ip-sh" node. module: ietf-bfd-ip-sh augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-sh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions | +--rw session* [interface dest-addr] | +--rw interface if:interface-ref | +--rw dest-addr inet:ip-address | +--rw source-addr? inet:ip-address | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw demand-enabled? boolean | | {demand-mode}? | +--rw admin-down? boolean | +--rw authentication! {authentication}? | | +--rw key-chain? key-chain:key-chain-ref | | +--rw meticulous? boolean | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? yang:counter32 | +--ro admin-down-count? yang:counter32 | +--ro receive-packet-count? yang:counter64 | +--ro send-packet-count? yang:counter64 | +--ro receive-invalid-packet-count? yang:counter64 | +--ro send-failed-packet-count? yang:counter64 +--rw interfaces* [interface] +--rw interface if:interface-ref +--rw authentication! {authentication}? +--rw key-chain? key-chain:key-chain-ref +--rw meticulous? boolean notifications: +---n singlehop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro interface? if:interface-ref +--ro echo-enabled? boolean 2.7. BFD IP Multihop Hierarchy An "ip-mh" node is added under the "bfd" node in "control-plane- protocol". The configuration data and operational state data for each BFD IP multihop session are under this "ip-mh" node. In the operational state model, we support multiple BFD multihop sessions per remote address (ECMP); the local discriminator is used as the key. module: ietf-bfd-ip-mh augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw ip-mh +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw session-groups +--rw session-group* [source-addr dest-addr] +--rw source-addr inet:ip-address +--rw dest-addr inet:ip-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? key-chain:key-chain-ref | +--rw meticulous? boolean +--rw tx-ttl? bfd-types:hops +--rw rx-ttl bfd-types:hops +--ro sessions* [] +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n multihop-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref 2.8. BFD-over-LAG Hierarchy A "lag" node is added under the "bfd" node in "control-plane- protocol". The configuration data and operational state data for each BFD LAG session are under this "lag" node. module: ietf-bfd-lag augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw lag +--rw micro-bfd-ipv4-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw micro-bfd-ipv6-session-statistics | +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw sessions +--rw session* [lag-name] +--rw lag-name if:interface-ref +--rw ipv4-dest-addr? | inet:ipv4-address +--rw ipv6-dest-addr? | inet:ipv6-address +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? key-chain:key-chain-ref | +--rw meticulous? boolean +--rw use-ipv4? boolean +--rw use-ipv6? boolean +--ro member-links* [member-link] +--ro member-link if:interface-ref +--ro micro-bfd-ipv4 | +--ro path-type? identityref | +--ro ip-encapsulation? boolean | +--ro local-discriminator? discriminator | +--ro remote-discriminator? discriminator | +--ro remote-multiplier? multiplier | +--ro demand-capability? boolean | | {demand-mode}? | +--ro source-port? inet:port-number | +--ro dest-port? inet:port-number | +--ro session-running | | +--ro session-index? uint32 | | +--ro local-state? state | | +--ro remote-state? state | | +--ro local-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-diagnostic? | | | iana-bfd-types:diagnostic | | +--ro remote-authenticated? boolean | | +--ro remote-authentication-type? | | | iana-bfd-types:auth-type | | | {authentication}? | | +--ro detection-mode? enumeration | | +--ro negotiated-tx-interval? uint32 | | +--ro negotiated-rx-interval? uint32 | | +--ro detection-time? uint32 | | +--ro echo-tx-interval-in-use? uint32 | | {echo-mode}? | +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro micro-bfd-ipv6 +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean | {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type | | {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics +--ro create-time? | yang:date-and-time +--ro last-down-time? | yang:date-and-time +--ro last-up-time? | yang:date-and-time +--ro down-count? | yang:counter32 +--ro admin-down-count? | yang:counter32 +--ro receive-packet-count? | yang:counter64 +--ro send-packet-count? | yang:counter64 +--ro receive-invalid-packet-count? | yang:counter64 +--ro send-failed-packet-count? yang:counter64 notifications: +---n lag-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro lag-name? if:interface-ref +--ro member-link? if:interface-ref 2.9. BFD-over-MPLS-LSPs Hierarchy An "mpls" node is added under the "bfd" node in "control-plane- protocol". The configuration is per MPLS FEC under this "mpls" node. In the operational state model, we support multiple BFD sessions per MPLS FEC (ECMP); the local discriminator is used as the key. The "mpls" node can be used in a network device (top level) or can be mounted in an LNE or network instance. module: ietf-bfd-mpls augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd: +--rw mpls +--ro summary | +--ro number-of-sessions? yang:gauge32 | +--ro number-of-sessions-up? yang:gauge32 | +--ro number-of-sessions-down? yang:gauge32 | +--ro number-of-sessions-admin-down? yang:gauge32 +--rw egress | +--rw enabled? boolean | +--rw local-multiplier? multiplier | +--rw (interval-config-type)? | | +--:(tx-rx-intervals) | | | +--rw desired-min-tx-interval? uint32 | | | +--rw required-min-rx-interval? uint32 | | +--:(single-interval) {single-minimum-interval}? | | +--rw min-interval? uint32 | +--rw authentication! {authentication}? | +--rw key-chain? key-chain:key-chain-ref | +--rw meticulous? boolean +--rw session-groups +--rw session-group* [mpls-fec] +--rw mpls-fec inet:ip-prefix +--rw local-multiplier? multiplier +--rw (interval-config-type)? | +--:(tx-rx-intervals) | | +--rw desired-min-tx-interval? uint32 | | +--rw required-min-rx-interval? uint32 | +--:(single-interval) {single-minimum-interval}? | +--rw min-interval? uint32 +--rw demand-enabled? boolean | {demand-mode}? +--rw admin-down? boolean +--rw authentication! {authentication}? | +--rw key-chain? key-chain:key-chain-ref | +--rw meticulous? boolean +--ro sessions* [] +--ro path-type? identityref +--ro ip-encapsulation? boolean +--ro local-discriminator? discriminator +--ro remote-discriminator? discriminator +--ro remote-multiplier? multiplier +--ro demand-capability? boolean {demand-mode}? +--ro source-port? inet:port-number +--ro dest-port? inet:port-number +--ro session-running | +--ro session-index? uint32 | +--ro local-state? state | +--ro remote-state? state | +--ro local-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-diagnostic? | | iana-bfd-types:diagnostic | +--ro remote-authenticated? boolean | +--ro remote-authentication-type? | | iana-bfd-types:auth-type {authentication}? | +--ro detection-mode? enumeration | +--ro negotiated-tx-interval? uint32 | +--ro negotiated-rx-interval? uint32 | +--ro detection-time? uint32 | +--ro echo-tx-interval-in-use? uint32 | {echo-mode}? +--ro session-statistics | +--ro create-time? | | yang:date-and-time | +--ro last-down-time? | | yang:date-and-time | +--ro last-up-time? | | yang:date-and-time | +--ro down-count? | | yang:counter32 | +--ro admin-down-count? | | yang:counter32 | +--ro receive-packet-count? | | yang:counter64 | +--ro send-packet-count? | | yang:counter64 | +--ro receive-invalid-packet-count? | | yang:counter64 | +--ro send-failed-packet-count? | yang:counter64 +--ro mpls-dest-address? inet:ip-address notifications: +---n mpls-notification +--ro local-discr? discriminator +--ro remote-discr? discriminator +--ro new-state? state +--ro state-change-reason? iana-bfd-types:diagnostic +--ro time-of-last-state-change? yang:date-and-time +--ro dest-addr? inet:ip-address +--ro source-addr? inet:ip-address +--ro session-index? uint32 +--ro path-type? identityref +--ro mpls-dest-address? inet:ip-address 2.10. Interaction with Other YANG Modules "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications" [RFC8532] describes how the Layer- Independent OAM Management in the Multi-Layer Environment (LIME) connectionless OAM model could be extended to support BFD. Also, the operation of the BFD data model depends on configuration parameters that are defined in other YANG modules. 2.10.1. "ietf-interfaces" Module The following boolean configuration is defined in "A YANG Data Model for Interface Management" [RFC8343]: /if:interfaces/if:interface/if:enabled If this configuration is set to "false", no BFD packets can be transmitted or received on that interface. 2.10.2. "ietf-ip" Module The following boolean configuration is defined in "A YANG Data Model for IP Management" [RFC8344]: /if:interfaces/if:interface/ip:ipv4/ip:enabled If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv4/ip:forwarding If this configuration is set to "false", no BFD IPv4 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:enabled If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. /if:interfaces/if:interface/ip:ipv6/ip:forwarding If this configuration is set to "false", no BFD IPv6 packets can be transmitted or received on that interface. 2.10.3. "ietf-mpls" Module The following boolean configuration is defined in "A YANG Data Model for MPLS Base" [RFC8960]: /rt:routing/mpls:mpls/mpls:interfaces/mpls:interface/ mpls:mpls-enabled If this configuration is set to "false", no BFD MPLS packets can be transmitted or received on that interface. 2.11. IANA BFD YANG Module This YANG module imports typedefs from [RFC5880] and references [RFC6428]. file "iana-bfd-types@2021-04-08.yang" module iana-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:iana-bfd-types"; prefix "iana-bfd-types"; organization "IANA"; contact "Internet Assigned Numbers Authority Postal: ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America Tel: +1 310 301 5800 "; description "This module defines YANG data types for IANA-registered BFD parameters. This YANG module is maintained by IANA and reflects the 'BFD Diagnostic Codes' and 'BFD Authentication Types' registries. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Type definitions */ typedef diagnostic { type enumeration { enum none { value 0; description "None."; } enum control-expiry { value 1; description "Control timer expiry."; } enum echo-failed { value 2; description "Echo failure."; } enum neighbor-down { value 3; description "Neighbor down."; } enum forwarding-reset { value 4; description "Forwarding reset."; } enum path-down { value 5; description "Path down."; } enum concatenated-path-down { value 6; description "Concatenated path down."; } enum admin-down { value 7; description "Administratively down."; } enum reverse-concatenated-path-down { value 8; description "Reverse concatenated path down."; } enum mis-connectivity-defect { value 9; description "Mis-connectivity defect as specified in RFC 6428."; reference "RFC 6428: Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile"; } } description "BFD diagnostic codes as defined in RFC 5880. Values are maintained in the 'BFD Diagnostic Codes' IANA registry. Range is 0 to 31."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } typedef auth-type { type enumeration { enum reserved { value 0; description "Reserved."; } enum simple-password { value 1; description "Simple password."; } enum keyed-md5 { value 2; description "Keyed MD5."; } enum meticulous-keyed-md5 { value 3; description "Meticulous Keyed MD5."; } enum keyed-sha1 { value 4; description "Keyed SHA1."; } enum meticulous-keyed-sha1 { value 5; description "Meticulous Keyed SHA1."; } } description "BFD authentication type as defined in RFC 5880. Values are maintained in the 'BFD Authentication Types' IANA registry. Range is 0 to 255."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } } 2.12. BFD Types YANG Module This YANG module imports typedefs from [RFC6991] and [RFC8177]. It also imports definitions from [RFC5880], [RFC5881], [RFC5883], [RFC5884], and [RFC7130], as well as the "control-plane-protocol" identity from [RFC8349]. file "ietf-bfd-types@2021-04-08.yang" module ietf-bfd-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-types"; prefix "bfd-types"; import iana-bfd-types { prefix "iana-bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix "yang"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } import ietf-key-chain { prefix "key-chain"; reference "RFC 8177: YANG Data Model for Key Chains"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains a collection of BFD-specific YANG data type definitions, as per RFC 5880, and also groupings that are common to other BFD YANG modules. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD) RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Feature definitions */ feature single-minimum-interval { description "This feature indicates that the server supports configuration of one minimum interval value that is used for both transmit and receive minimum intervals."; } feature authentication { description "This feature indicates that the server supports BFD authentication."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.7"; } feature demand-mode { description "This feature indicates that the server supports BFD Demand mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.6"; } feature echo-mode { description "This feature indicates that the server supports BFD Echo mode."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.4"; } /* * Identity definitions */ identity bfdv1 { base "rt:control-plane-protocol"; description "BFD protocol version 1."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } identity path-type { description "Base identity for the BFD path type. The path type indicates the type of path on which BFD is running."; } identity path-ip-sh { base path-type; description "BFD on IP single-hop."; reference "RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)"; } identity path-ip-mh { base path-type; description "BFD on IP multihop paths."; reference "RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths"; } identity path-mpls-te { base path-type; description "BFD on MPLS Traffic Engineering."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"; } identity path-mpls-lsp { base path-type; description "BFD on an MPLS Label Switched Path."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"; } identity path-lag { base path-type; description "Micro-BFD on LAG member links."; reference "RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces"; } identity encap-type { description "Base identity for BFD encapsulation type."; } identity encap-ip { base encap-type; description "BFD with IP encapsulation."; } /* * Type definitions */ typedef discriminator { type uint32; description "BFD Discriminator as described in RFC 5880."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD)"; } typedef state { type enumeration { enum adminDown { value 0; description "'adminDown' state."; } enum down { value 1; description "'Down' state."; } enum init { value 2; description "'Init' state."; } enum up { value 3; description "'Up' state."; } } description "BFD states as defined in RFC 5880."; } typedef multiplier { type uint8 { range 1..255; } description "BFD multiplier as described in RFC 5880."; } typedef hops { type uint8 { range 1..255; } description "This corresponds to Time To Live for IPv4 and corresponds to the hop limit for IPv6."; } /* * Groupings */ grouping auth-parms { description "Grouping for BFD authentication parameters (see Section 6.7 of RFC 5880)."; container authentication { if-feature authentication; presence "Enables BFD authentication (see Section 6.7 of RFC 5880)."; description "Parameters for BFD authentication."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.7"; leaf key-chain { type key-chain:key-chain-ref; description "Name of the 'key-chain' as per RFC 8177."; } leaf meticulous { type boolean; description "Enables a meticulous mode as per Section 6.7 of RFC 5880."; } } } grouping base-cfg-parms { description "BFD grouping for base configuration parameters."; leaf local-multiplier { type multiplier; default 3; description "Multiplier transmitted by the local system."; } choice interval-config-type { default tx-rx-intervals; description "Two interval values or one value used for both transmit and receive."; case tx-rx-intervals { leaf desired-min-tx-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval of control packets."; } leaf required-min-rx-interval { type uint32; units microseconds; default 1000000; description "Required minimum receive interval of control packets."; } } case single-interval { if-feature single-minimum-interval; leaf min-interval { type uint32; units microseconds; default 1000000; description "Desired minimum transmit interval and required minimum receive interval of control packets."; } } } } grouping client-cfg-parms { description "BFD grouping for configuration parameters used by BFD clients, e.g., IGP or MPLS."; leaf enabled { type boolean; default false; description "Indicates whether BFD is enabled."; } uses base-cfg-parms; } grouping common-cfg-parms { description "BFD grouping for common configuration parameters."; uses base-cfg-parms; leaf demand-enabled { if-feature demand-mode; type boolean; default false; description "To enable Demand mode."; } leaf admin-down { type boolean; default false; description "Indicates whether the BFD session is administratively down."; } uses auth-parms; } grouping all-session { description "BFD session operational information."; leaf path-type { type identityref { base path-type; } config "false"; description "BFD path type. This indicates the path type that BFD is running on."; } leaf ip-encapsulation { type boolean; config "false"; description "Indicates whether BFD encapsulation uses IP."; } leaf local-discriminator { type discriminator; config "false"; description "Local discriminator."; } leaf remote-discriminator { type discriminator; config "false"; description "Remote discriminator."; } leaf remote-multiplier { type multiplier; config "false"; description "Remote multiplier."; } leaf demand-capability { if-feature demand-mode; type boolean; config "false"; description "Local Demand mode capability."; } leaf source-port { when "../ip-encapsulation = 'true'" { description "Source port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Source UDP port."; } leaf dest-port { when "../ip-encapsulation = 'true'" { description "Destination port valid only when IP encapsulation is used."; } type inet:port-number; config "false"; description "Destination UDP port."; } container session-running { config "false"; description "BFD 'session-running' information."; leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } leaf local-state { type state; description "Local state."; } leaf remote-state { type state; description "Remote state."; } leaf local-diagnostic { type iana-bfd-types:diagnostic; description "Local diagnostic."; } leaf remote-diagnostic { type iana-bfd-types:diagnostic; description "Remote diagnostic."; } leaf remote-authenticated { type boolean; description "Indicates whether incoming BFD control packets are authenticated."; } leaf remote-authentication-type { when "../remote-authenticated = 'true'" { description "Only valid when incoming BFD control packets are authenticated."; } if-feature authentication; type iana-bfd-types:auth-type; description "Authentication type of incoming BFD control packets."; } leaf detection-mode { type enumeration { enum async-with-echo { value "1"; description "Async with echo."; } enum async-without-echo { value "2"; description "Async without echo."; } enum demand-with-echo { value "3"; description "Demand with echo."; } enum demand-without-echo { value "4"; description "Demand without echo."; } } description "Detection mode."; } leaf negotiated-tx-interval { type uint32; units microseconds; description "Negotiated transmit interval."; } leaf negotiated-rx-interval { type uint32; units microseconds; description "Negotiated receive interval."; } leaf detection-time { type uint32; units microseconds; description "Detection time."; } leaf echo-tx-interval-in-use { when "../../path-type = 'bfd-types:path-ip-sh'" { description "Echo is supported for IP single-hop only."; } if-feature echo-mode; type uint32; units microseconds; description "Echo transmit interval in use."; } } container session-statistics { config "false"; description "BFD per-session statistics."; leaf create-time { type yang:date-and-time; description "Time and date when this session was created."; } leaf last-down-time { type yang:date-and-time; description "Time and date of the last time this session went down."; } leaf last-up-time { type yang:date-and-time; description "Time and date of the last time this session went up."; } leaf down-count { type yang:counter32; description "The number of times this session has transitioned to the 'down' state."; } leaf admin-down-count { type yang:counter32; description "The number of times this session has transitioned to the 'admin-down' state."; } leaf receive-packet-count { type yang:counter64; description "Count of received packets in this session. This includes valid and invalid received packets."; } leaf send-packet-count { type yang:counter64; description "Count of sent packets in this session."; } leaf receive-invalid-packet-count { type yang:counter64; description "Count of invalid received packets in this session."; } leaf send-failed-packet-count { type yang:counter64; description "Count of packets that failed to be sent in this session."; } } } grouping session-statistics-summary { description "Grouping for session statistics summary."; container summary { config false; description "BFD session statistics summary."; leaf number-of-sessions { type yang:gauge32; description "Number of BFD sessions."; } leaf number-of-sessions-up { type yang:gauge32; description "Number of BFD sessions currently in the 'Up' state (as defined in RFC 5880)."; } leaf number-of-sessions-down { type yang:gauge32; description "Number of BFD sessions currently in the 'Down' or 'Init' state but not 'adminDown' (as defined in RFC 5880)."; } leaf number-of-sessions-admin-down { type yang:gauge32; description "Number of BFD sessions currently in the 'adminDown' state (as defined in RFC 5880)."; } } } grouping notification-parms { description "This group describes common parameters that will be sent as part of BFD notifications."; leaf local-discr { type discriminator; description "BFD local discriminator."; } leaf remote-discr { type discriminator; description "BFD remote discriminator."; } leaf new-state { type state; description "Current BFD state."; } leaf state-change-reason { type iana-bfd-types:diagnostic; description "Reason for the BFD state change."; } leaf time-of-last-state-change { type yang:date-and-time; description "Calendar time of the most recent previous state change."; } leaf dest-addr { type inet:ip-address; description "BFD peer address."; } leaf source-addr { type inet:ip-address; description "BFD local address."; } leaf session-index { type uint32; description "An index used to uniquely identify BFD sessions."; } leaf path-type { type identityref { base path-type; } description "BFD path type."; } } } 2.13. BFD Top-Level YANG Module This YANG module imports and augments "/routing/control-plane- protocols/control-plane-protocol" from [RFC8349]. It also references [RFC5880]. file "ietf-bfd@2021-04-08.yang" module ietf-bfd { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd"; prefix "bfd"; import ietf-bfd-types { prefix "bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains the YANG definition for BFD parameters as per RFC 5880. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD) RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol" { when "derived-from-or-self(rt:type, 'bfd-types:bfdv1')" { description "This augmentation is only valid for a control-plane protocol instance of BFD (type 'bfdv1')."; } description "BFD augmentation."; container bfd { description "BFD top-level container."; uses bfd-types:session-statistics-summary; } } } 2.14. BFD IP Single-Hop YANG Module This YANG module imports "interface-ref" from [RFC8343] and typedefs from [RFC6991]. It also imports and augments "/routing/control- plane-protocols/control-plane-protocol" from [RFC8349], and it references [RFC5881]. file "ietf-bfd-ip-sh@2021-04-08.yang" module ietf-bfd-ip-sh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh"; prefix "bfd-ip-sh"; import ietf-bfd-types { prefix "bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-bfd { prefix "bfd"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains the YANG definition for BFD IP single-hop as per RFC 5881. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 5881: Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP single-hop."; container ip-sh { description "BFD IP single-hop top-level container."; uses bfd-types:session-statistics-summary; container sessions { description "BFD IP single-hop sessions."; list session { key "interface dest-addr"; description "List of IP single-hop sessions."; leaf interface { type if:interface-ref; description "Interface on which the BFD session is running."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } leaf source-addr { type inet:ip-address; description "Local IP address."; } uses bfd-types:common-cfg-parms; uses bfd-types:all-session; } } list interfaces { key "interface"; description "List of interfaces."; leaf interface { type if:interface-ref; description "BFD information for this interface."; } uses bfd-types:auth-parms; } } } /* * Notifications */ notification singlehop-notification { description "Notification for BFD single-hop session state change. An implementation may rate-limit notifications, e.g., when a session is continuously changing state."; uses bfd-types:notification-parms; leaf interface { type if:interface-ref; description "Interface to which this BFD session belongs."; } leaf echo-enabled { type boolean; description "Indicates whether Echo was enabled for BFD."; } } } 2.15. BFD IP Multihop YANG Module This YANG module imports typedefs from [RFC6991]. It also imports and augments "/routing/control-plane-protocols/control-plane- protocol" from [RFC8349], and it references [RFC5883]. file "ietf-bfd-ip-mh@2021-04-08.yang" module ietf-bfd-ip-mh { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh"; prefix "bfd-ip-mh"; import ietf-bfd-types { prefix "bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-bfd { prefix "bfd"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains the YANG definition for BFD IP multihop as per RFC 5883. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 5883: Bidirectional Forwarding Detection (BFD) for Multihop Paths RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for IP multihop."; container ip-mh { description "BFD IP multihop top-level container."; uses bfd-types:session-statistics-summary; container session-groups { description "BFD IP multihop session groups."; list session-group { key "source-addr dest-addr"; description "Group of BFD IP multihop sessions (for ECMP). A group of sessions is between one source and one destination. Each session has a different field in the UDP/IP header for ECMP."; leaf source-addr { type inet:ip-address; description "Local IP address."; } leaf dest-addr { type inet:ip-address; description "IP address of the peer."; } uses bfd-types:common-cfg-parms; leaf tx-ttl { type bfd-types:hops; default 255; description "Hop count of outgoing BFD control packets."; } leaf rx-ttl { type bfd-types:hops; mandatory true; description "Minimum allowed hop count value for incoming BFD control packets. Control packets whose hop count is lower than this value are dropped."; } list sessions { config false; description "The multiple BFD sessions between a source and a destination."; uses bfd-types:all-session; } } } } } /* * Notifications */ notification multihop-notification { description "Notification for BFD multihop session state change. An implementation may rate-limit notifications, e.g., when a session is continuously changing state."; uses bfd-types:notification-parms; } } 2.16. BFD-over-LAG YANG Module This YANG module imports "interface-ref" from [RFC8343] and typedefs from [RFC6991]. It also imports and augments "/routing/control- plane-protocols/control-plane-protocol" from [RFC8349]. Additionally, it references [RFC7130]. file "ietf-bfd-lag@2021-04-08.yang" module ietf-bfd-lag { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-lag"; prefix "bfd-lag"; import ietf-bfd-types { prefix "bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-bfd { prefix "bfd"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-interfaces { prefix "if"; reference "RFC 8343: A YANG Data Model for Interface Management"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains the YANG definition for BFD-over-LAG interfaces as per RFC 7130. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for a LAG."; container lag { description "BFD-over-LAG top-level container."; container micro-bfd-ipv4-session-statistics { description "Micro-BFD IPv4 session counters."; uses bfd-types:session-statistics-summary; } container micro-bfd-ipv6-session-statistics { description "Micro-BFD IPv6 session counters."; uses bfd-types:session-statistics-summary; } container sessions { description "BFD-over-LAG sessions."; list session { key "lag-name"; description "List of BFD-over-LAG sessions."; leaf lag-name { type if:interface-ref ; description "Name of the LAG."; } leaf ipv4-dest-addr { type inet:ipv4-address; description "IPv4 address of the peer, for IPv4 micro-BFD."; } leaf ipv6-dest-addr { type inet:ipv6-address; description "IPv6 address of the peer, for IPv6 micro-BFD."; } uses bfd-types:common-cfg-parms; leaf use-ipv4 { type boolean; description "Using IPv4 micro-BFD."; } leaf use-ipv6 { type boolean; description "Using IPv6 micro-BFD."; } list member-links { key "member-link"; config false; description "Micro-BFD over a LAG. This represents one member link."; leaf member-link { type if:interface-ref; description "Member link on which micro-BFD is running."; } container micro-bfd-ipv4 { when "../../use-ipv4 = 'true'" { description "Needed only if IPv4 is used."; } description "Micro-BFD IPv4 session state on a member link."; uses bfd-types:all-session; } container micro-bfd-ipv6 { when "../../use-ipv6 = 'true'" { description "Needed only if IPv6 is used."; } description "Micro-BFD IPv6 session state on a member link."; uses bfd-types:all-session; } } } } } } /* * Notifications */ notification lag-notification { description "Notification for BFD-over-LAG session state change. An implementation may rate-limit notifications, e.g., when a session is continuously changing state."; uses bfd-types:notification-parms; leaf lag-name { type if:interface-ref; description "LAG interface name."; } leaf member-link { type if:interface-ref; description "Member link on which BFD is running."; } } } 2.17. BFD-over-MPLS YANG Module This YANG module imports typedefs from [RFC6991]. It also imports and augments "/routing/control-plane-protocols/control-plane- protocol" from [RFC8349]. Additionally, it references [RFC5586] and [RFC5884]. file "ietf-bfd-mpls@2021-04-08.yang" module ietf-bfd-mpls { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-mpls"; prefix "bfd-mpls"; import ietf-bfd-types { prefix "bfd-types"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-bfd { prefix "bfd"; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } import ietf-inet-types { prefix "inet"; reference "RFC 6991: Common YANG Data Types"; } import ietf-routing { prefix "rt"; reference "RFC 8349: A YANG Data Model for Routing Management (NMDA Version)"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains the YANG definition for BFD parameters for MPLS LSPs as per RFC 5884. Copyright (c) 2021 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; revision 2021-04-08 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Identity definitions */ identity encap-gach { base bfd-types:encap-type; description "BFD with G-ACh encapsulation as per RFC 5586."; reference "RFC 5586: MPLS Generic Associated Channel"; } identity encap-ip-gach { base bfd-types:encap-type; description "BFD with IP and G-ACh encapsulation as per RFC 5586."; } /* * Groupings */ grouping encap-cfg { description "Configuration for BFD encapsulation."; leaf encap { type identityref { base bfd-types:encap-type; } default bfd-types:encap-ip; description "BFD encapsulation."; } } grouping mpls-dest-address { description "Destination address as per RFC 5884."; reference "RFC 5884: Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)"; leaf mpls-dest-address { type inet:ip-address; config "false"; description "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } /* * Augments */ augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd" { description "BFD augmentation for MPLS."; container mpls { description "BFD MPLS top-level container."; uses bfd-types:session-statistics-summary; container egress { description "Egress configuration."; uses bfd-types:client-cfg-parms; uses bfd-types:auth-parms; } container session-groups { description "BFD-over-MPLS session groups."; list session-group { key "mpls-fec"; description "Group of BFD MPLS sessions (for ECMP). A group of sessions is for one FEC. Each session has a different field in the UDP/IP header for ECMP."; leaf mpls-fec { type inet:ip-prefix; description "MPLS FEC."; } uses bfd-types:common-cfg-parms; list sessions { config false; description "The BFD sessions for an MPLS FEC. The local discriminator is unique for each session in the group."; uses bfd-types:all-session; uses bfd-mpls:mpls-dest-address; } } } } } /* * Notifications */ notification mpls-notification { description "Notification for BFD-over-MPLS FEC session state change. An implementation may rate-limit notifications, e.g., when a session is continuously changing state."; uses bfd-types:notification-parms; leaf mpls-dest-address { type inet:ip-address; description "Destination address as per RFC 5884. Needed if IP encapsulation is used."; } } } 3. Data Model Examples This section presents some simple and illustrative examples of how to configure BFD. The examples are represented in XML [W3C.REC-xml-20081126]. 3.1. IP Single-Hop The following is an example configuration for a BFD IP single-hop session. The desired transmit interval and the required receive interval are both set to 10 ms. eth0 ianaift:ethernetCsmacd bfd-types:bfdv1 name:BFD eth0 2001:db8:0:113::101 10000 10000 3.2. IP Multihop The following is an example configuration for a BFD IP multihop session group. The desired transmit interval and the required receive interval are both set to 150 ms. bfd-types:bfdv1 name:BFD 2001:db8:0:113::103 2001:db8:0:114::100 150000 150000 240 3.3. LAG The following is an example of BFD configuration for a LAG session. In this case, an interface named "Bundle-Ether1" of interface type "ieee8023adLag" has a desired transmit interval and required receive interval set to 10 ms. Bundle-Ether1 ianaift:ieee8023adLag bfd-types:bfdv1 name:BFD Bundle-Ether1 2001:db8:112::16 100000 100000 true 3.4. MPLS The following is an example of BFD configured for an MPLS LSP. In this case, the desired transmit interval and required receive interval are both set to 250 ms. bfd-types:bfdv1 name:BFD 2001:db8:114::/116 250000 250000 4. Security Considerations The YANG modules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ sessions: This list specifies the IP single-hop BFD sessions. Data nodes "local-multiplier", "desired-min-tx-interval", "required-min-rx-interval", and "min-interval" all impact the BFD IP single-hop session. The "source-addr" and "dest-addr" data nodes can be used to send BFD packets to unwitting recipients. [RFC5880] describes how BFD mitigates such threats. Authentication data nodes "key-chain" and "meticulous" impact the security of the BFD IP single-hop session. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-group: This list specifies the IP multihop BFD session groups. Data nodes "local-multiplier", "desired-min-tx-interval", "required-min-rx-interval", and "min-interval" all impact the BFD IP multihop session. The "source-addr" and "dest-addr" data nodes can be used to send BFD packets to unwitting recipients. [RFC5880] describes how BFD mitigates such threats. Authentication data nodes "key-chain" and "meticulous" impact the security of the BFD IP multihop session. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ sessions: This list specifies the BFD sessions over a LAG. Data nodes "local-multiplier", "desired-min-tx-interval", "required-min-rx-interval", and "min-interval" all impact the BFD- over-LAG session. The "ipv4-dest-addr" and "ipv6-dest-addr" data nodes can be used to send BFD packets to unwitting recipients. [RFC5880] describes how BFD mitigates such threats. Authentication data nodes "key-chain" and "meticulous" impact the security of the BFD-over-LAG session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-group: This list specifies the session groups for BFD over MPLS. Data nodes "local-multiplier", "desired-min-tx-interval", "required-min-rx-interval", and "min-interval" all impact the BFD- over-MPLS-LSPs session. Authentication data nodes "key-chain" and "meticulous" impact the security of the BFD-over-MPLS-LSPs session. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ egress: Data nodes "local-multiplier", "desired-min-tx-interval", "required-min-rx-interval", and "min-interval" all impact the BFD- over-MPLS-LSPs sessions for which this device is an MPLS LSP egress node. Authentication data nodes "key-chain" and "meticulous" impact the security of the BFD-over-MPLS-LSPs sessions for which this device is an MPLS LSP egress node. The YANG modules have writable data nodes that can be used for the creation of BFD sessions and the modification of BFD session parameters. The system should "police" the creation of BFD sessions to prevent new sessions from causing existing BFD sessions to fail. In the case of BFD session modification, the BFD protocol has mechanisms in place that allow for in-service modification. When BFD clients are used to modify BFD configuration (as described in Section 2.1), the BFD clients need to be included in an analysis of the security properties of the system that uses BFD (e.g., when considering the authentication and authorization of control actions). In many cases, BFD is not the most vulnerable portion of such a composite system, since BFD is limited to generating well-defined traffic at a fixed rate on a given path; in the case of an IGP acting as a BFD client, attacking the IGP could cause more broad-scale disruption than would (de)configuring a BFD session. Some of the readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: /routing/control-plane-protocols/control-plane-protocol/bfd/ip-sh/ summary: Access to this information discloses the number of BFD IP single- hop sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions for which the user does not have read access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip- sh/sessions/session/: Access to data nodes "local-discriminator" and "remote- discriminator" (combined with the data nodes in the authentication container) provides the ability to spoof BFD IP single-hop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ summary: Access to this information discloses the number of BFD IP multihop sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions for which the user does not have read access. /routing/control-plane-protocols/control-plane-protocol/bfd/ip-mh/ session-groups/session-group/sessions: Access to data nodes "local-discriminator" and "remote- discriminator" (combined with the data nodes in the session group's authentication container) provides the ability to spoof BFD IP multihop packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv4-session-statistics/summary: Access to this information discloses the number of micro-BFD IPv4 LAG sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions for which the user does not have read access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro- bfd-ipv4: Access to data nodes "local-discriminator" and "remote- discriminator" (combined with the data nodes in the session's authentication container) provides the ability to spoof BFD IPv4 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/lag/ micro-bfd-ipv6-session-statistics/summary: Access to this information discloses the number of micro-BFD IPv6 LAG sessions that are in the "up", "down", or "admin-down" state. The counters include BFD sessions for which the user does not have read access. /routing/control-plane-protocols/control-plane- protocol/bfd/lag/sessions/session/member-links/member-link/micro- bfd-ipv6: Access to data nodes "local-discriminator" and "remote- discriminator" (combined with the data nodes in the session's authentication container) provides the ability to spoof BFD IPv6 LAG packets. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ summary: Access to this information discloses the number of BFD sessions over MPLS LSPs that are in the "up", "down", or "admin-down" state. The counters include BFD sessions for which the user does not have read access. /routing/control-plane-protocols/control-plane-protocol/bfd/mpls/ session-groups/session-group/sessions: Access to data nodes "local-discriminator" and "remote- discriminator" (combined with the data nodes in the session group's authentication container) provides the ability to spoof BFD-over-MPLS-LSPs packets. 5. IANA Considerations This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:iana-bfd-types Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd-types Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]: Name: iana-bfd-types Namespace: urn:ietf:params:xml:ns:yang:iana-bfd-types Prefix: iana-bfd-types Reference: RFC 0000 Name: ietf-bfd-types Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-types Prefix: bfd-types Reference: RFC 0000 Name: ietf-bfd Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd Prefix: bfd Reference: RFC 0000 Name: ietf-bfd-ip-sh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-sh Prefix: bfd-ip-sh Reference: RFC 0000 Name: ietf-bfd-ip-mh Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-ip-mh Prefix: bfd-ip-mh Reference: RFC 0000 Name: ietf-bfd-lag Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-lag Prefix: bfd-lag Reference: RFC 0000 Name: ietf-bfd-mpls Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-mpls Prefix: bfd-mpls Reference: RFC 0000 5.1. IANA-Maintained "iana-bfd-types" Module This document defines the initial version of the IANA-maintained "iana-bfd-types" YANG module. The "iana-bfd-types" YANG module mirrors the "BFD Diagnostic Codes" and "BFD Authentication Types" registries at . Whenever these registries change, IANA must update the "iana-bfd-types" YANG module. 6. References 6.1. Normative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional Forwarding Detection (BFD)", RFC 5882, DOI 10.17487/RFC5882, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 2014, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, DOI 10.17487/RFC8177, June 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, DOI 10.17487/RFC8349, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A YANG Data Model for MPLS Base", RFC 8960, DOI 10.17487/RFC8960, November 2020, . [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . 6.2. Informative References [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Data Model for Network Instances", RFC 8529, DOI 10.17487/RFC8529, March 2019, . [RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X. Liu, "YANG Model for Logical Network Elements", RFC 8530, DOI 10.17487/RFC8530, March 2019, . [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, . Appendix A. Echo Function Configuration Example As mentioned in Section 2.1.2, the mechanism to start and stop the Echo function, as defined in [RFC5880] and discussed in [RFC5881], is implementation specific. In this appendix, we provide an example of how the Echo function can be implemented via configuration. module: example-bfd-echo augment /rt:routing/rt:control-plane-protocols /rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh /bfd-ip-sh:sessions: +--rw echo {bfd-types:echo-mode}? +--rw desired-min-echo-tx-interval? uint32 +--rw required-min-echo-rx-interval? uint32 A.1. Example YANG Module for BFD Echo Function Configuration This appendix provides an example YANG module for configuration of the BFD Echo function. It imports and augments "/routing/control- plane-protocols/control-plane-protocol" from [RFC8349], and it references [RFC5880]. module example-bfd-echo { namespace "tag:example.com,2018:example-bfd-echo"; prefix "example-bfd-echo"; import ietf-bfd-types { prefix "bfd-types"; } import ietf-bfd { prefix "bfd"; } import ietf-bfd-ip-sh { prefix "bfd-ip-sh"; } import ietf-routing { prefix "rt"; } organization "IETF BFD Working Group"; contact "WG Web: WG List: Editor: Reshad Rahman Editor: Lianshu Zheng Editor: Mahesh Jethanandani "; description "This module contains an example YANG augmentation for configuration of the BFD Echo function. Copyright (c) 2020 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 0000; see the RFC itself for full legal notices."; revision 2018-08-01 { description "Initial revision."; reference "RFC 0000: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } /* * Groupings */ grouping echo-cfg-parms { description "BFD grouping for Echo configuration parameters."; leaf desired-min-echo-tx-interval { type uint32; units microseconds; default 0; description "This is the minimum interval that the local system would like to use when transmitting BFD Echo packets. If 0, the Echo function as defined in BFD (RFC 5880) is disabled."; } leaf required-min-echo-rx-interval { type uint32; units microseconds; default 0; description "This is the Required Min Echo RX Interval as defined in BFD (RFC 5880)."; } } augment "/rt:routing/rt:control-plane-protocols/" + "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/" + "bfd-ip-sh:sessions" { description "Augmentation for the BFD Echo function."; container echo { if-feature bfd-types:echo-mode; description "BFD Echo function container."; uses echo-cfg-parms; } } } Acknowledgments We would like to thank Nobo Akiya and Jeff Haas for their encouragement on this work. We would also like to thank Tom Petch for his comments on the draft. We would also like to thank Acee Lindem for his guidance. Thanks also to Juergen Schoenwaelder, who was instrumental in improving the YANG modules. Authors' Addresses Reshad Rahman (editor) Canada Email: reshad@yahoo.com Lianshu Zheng (editor) Huawei Technologies China Email: vero.zheng@huawei.com Mahesh Jethanandani (editor) Xoriant Corporation 1248 Reamwood Ave Sunnyvale, California 94089 United States of America Email: mjethanandani@gmail.com Santosh Pallagatti RtBrick India Email: santosh.pallagatti@gmail.com Greg Mirsky ZTE Corporation Email: gregimirsky@gmail.com --Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On Jul 27, 2021, at 11:49 AM, John Scudder = <jgs=3D40juniper.net@dmarc.ietf.org> wrote:

RFC Editor state is MISSREF, as part of cluster C336: https://www.rfc-editor.org/cluster_info.php?cid=3DC336. = If I=E2=80=99m untangling the information there correctly, I think = it=E2=80=99s blocked on (at least) draft-ietf-teas-yang-te. 

Was the surgery that Tom mentions, expected to clear it = out of MISSREF? If so, please give me some more details (either in this = thread or offline) and I can check in with the RFC Editor.

Thanks,

=E2=80=94John

On Jul 27, 2021, at 10:56 AM, Reshad Rahman <reshad@yahoo.com> = wrote:


Adding John (AD).

On Tuesday, July 27, 2021, 10:45:07 a.m. EDT, tom petch = <ietfa@btconnect.com> wrote:


From: Reshad Rahman <reshad@yahoo.com>
Sent: 21 May 2021 00:03

<I should have sent this a few weeks ago when it got done>

FYI, Mahesh did the extraction of the mpls-te from draft-ietf-bfd-yang = and it's been submitted to the RFC Editor.

<tp>
Two months have passed and I see no change in the RFC Editor = queue.  Whatever was done would appear to have been not = enough.  I was expecting an action by the AD to be required and = have seen no sign thereof which may be relevant.

Tom Petch


Regards,
Reshad.

=EF=BB=BFOn 2021-03-22, 3:30 PM, "Rtg-bfd on behalf of Yingzhen Qu" = <rtg-bfd-bounces@ietf.org on behalf of yingzhen.ietf@gmail.com> wrote:

    Hi,

    I also support the split of ietf-bfd-mpls-te module from = the base BFD module, so modules like ietf-ospf and ietf-isis can = progress.

    Thanks,
    Yingzhen

    > On Mar 22, 2021, at 2:33 AM, tom petch <ietfa@btconnect.com> wrote:
    >
    >
    >
    > From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf = of Reshad Rahman <reshad=3D40yahoo.com@dmarc.ietf.org>
    > Sent: 19 March 2021 18:58
=     > To: rtg-bfd@ietf. org
    > Subject: Draft minutes for BFD @ IETF110
    >
    > BFD WG,
    >
    > Draft minutes have been posted @ https://datatracker.ietf.org/doc/minutes-110-bfd/
    >
    > Please provide comments to the list by April 2nd.
    > <tp>
    >
    > I support Acee's suggestion that the TE part should = be split from the BFD YANG draft so that the other three WG, who have = been held up for years, can progress.
    >
    > Tom Petch
    >
    > Copying the LSR WG.
    >
    >
    > Meeting recording is @ https://www.youtube.com/watch?v=3DvSqfJJ3gOc0
    >
    > Regards,
    > Reshad.
    >
    > _______________________________________________
    > Lsr mailing list
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr


Mahesh Jethanandani



= --Apple-Mail=_603D5FD2-3212-4384-AADA-F6A6213A504C-- --Apple-Mail=_EE3371DF-8722-4709-8947-9CD67EB67772-- From nobody Tue Jul 27 13:16:17 2021 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C843A11DF; Tue, 27 Jul 2021 13:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=vGLUFvOx; dkim=pass (1024-bit key) header.d=juniper.net header.b=JA0Mpsaz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKTEBVpsShEs; Tue, 27 Jul 2021 13:16:02 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D11293A11D4; Tue, 27 Jul 2021 13:15:41 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16RJs4fE011413; Tue, 27 Jul 2021 13:15:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=EwC7PKBHR5kWSpjMz2Dta8iDnIzqzXpkwBgguLW98P4=; b=vGLUFvOxdl3/woxnjGa1/84HdG9cb7pYWaO3VPtJFGX2CwhPrTFXdQWdRNf4DjlwaPXR 55ydLQ2wK3BBGWM1i9bENCJiHblIkF/aaRsm8wSiIKrwJbHmeP9YBYJpcxReDIbtVozY 14fdxIdtm4hrHKCZYn0QVMPX97fPWn/4f/hFCjE8+cfALdHkYAOmLDJtJ3N3GzSACegz MwbB4CUt2rs+RpjqAm4+5cq8CfbTb9HGzdaOv5G2P/nC3TbfY7O743CZqK45r3ECDE+W aBe4YN+mV+5rso/Uk99mhTMfK8DR7OjyKZIb8FFZlBWuuK8nPo3gSKeIi4+aaydrtXu5 rw== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2173.outbound.protection.outlook.com [104.47.59.173]) by mx0b-00273201.pphosted.com with ESMTP id 3a2d169dcf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Jul 2021 13:15:36 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XFId/sTTeURvRxEnxoCJF7Uf0w1tDUrQlTVlAZjxQaoIfwG64GsBYAIb/GCm4pAVh4eJutApEiWWLeY1HCpnycRvegW21YgHRqeLk8A7vUuXBQsWn2tSgCRNyTzS9N7buHexXou2RrpCYV7V5ULfS/S9Y8+s7I6ozssPihJyWcKbdERL3LX+kxJyf5S+hJwFfN/u/NZ0P45Xz3l875LgzMH4HP1kCE0jQGcsU4Sp3BrqgaESaMP7kPWOBEn0W4+0UOmR9RDWF4Y7v195xJaYwGAVyTaGmnBrDnx+Kp/lybEFcSKxWuwcJq13nun4oYaEFhRn9NpSY/iQ8rW5yTZp/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EwC7PKBHR5kWSpjMz2Dta8iDnIzqzXpkwBgguLW98P4=; b=fEsXdWeUpihYBLeRbxe1t4MahaRiQki61gcxe8MrsnRgnHWuI5UKJEjW/SPcqmOjsODQzB9fpD1rsLbReRs872YXc8T6l/B1KkBg+M0bwBVCQErYkvdoonHm/AUu1sVaRzzGrtxgU7e1579GSU/AWCisaL51uPLJU9f/c0+1anVSc2//blU9yFEvTvdWsee14VLwH9hyEyKmiQWuuxLIHAczXWCsR0ji/yagkNS9O1+FwiphjHqbfMpMoxiIkMnPQpfkHpn3lqw0XlIURs87Q2LoJeD/S6ldm0WtMBdKMbJtkBdKtp+VWbjHMMAHOHG7M7wq55/WkfmXRoIRt7NXEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EwC7PKBHR5kWSpjMz2Dta8iDnIzqzXpkwBgguLW98P4=; b=JA0MpsazC3Pegic7zZFDKXknvhC6ixC7JixNeiIGT6tywU3iQvP3F+646gwkT6gX5qwfliZJyuxXciEHGNcGf9o2+fYMWtNZxi0UYrr8XKCwVut20XcM7dWtSr2WltYsfo9/B0vlQymNN4qQTxJ/S98EMjMjPu2yX0iXSknLa3Q= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6046.namprd05.prod.outlook.com (2603:10b6:208:cd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.14; Tue, 27 Jul 2021 20:15:32 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::e40e:672f:e689:cd0c%7]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 20:15:32 +0000 From: John Scudder To: Mahesh Jethanandani CC: Reshad Rehman , "lsr@ietf.org" , Yingzhen Qu , tom petch , "rtg-bfd@ietf. org" Subject: Re: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Topic: [Lsr] Split was Re: Draft minutes for BFD @ IETF110 Thread-Index: AQHXHPHlY/eJmrY4iU6TuKlPHzUxeKqPww8AgACmZgCAXPVdgIBqUzQAgAADXoCAAEDjAIAAEdEAgAAGUIA= Date: Tue, 27 Jul 2021 20:15:32 +0000 Message-ID: <84484E76-6660-4C0E-8A2B-6CFB009C2963@juniper.net> References: <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93.ref@yahoo.com> <47E2C01B-AE6F-4697-9C49-3A2EEAB78F93@yahoo.com> <40AB32BD-3138-460F-B385-B8BA6D1EA8FB@gmail.com> <781624976.145062.1627397815151@mail.yahoo.com> <4478FB07-361E-4152-89E5-4E0193CF1BE1@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.100.0.2.22) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f6072d0e-3e90-4745-b5fa-08d9513b4946 x-ms-traffictypediagnostic: MN2PR05MB6046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NfwXkO5+XWy+OsilmZTXUgBdTnwVo71EuBT4cDgRgCapBppzO6KSBHo/I/TjG81AnvqKJtuOz8Zn+jxvt38n76HNugwIx9b8PRwPGwRb7ngkTOafn7Fr1PUpxYUnaR4olgGJDeS7BM6bS31F677FY/WSC5eysFeCoN1+JXqM129bYgKT4LFK8pxZEafathARmuhTRtP3QETiF7qavMntWEZezjJCdFjPfdtVp0rmnZz/QqbbfkGoIbCOVWR8nzxzBwC5PdRTNH6fyuR5JDfsPTRKfi5yp/ITPl1wewtV8ayTuaURTw/ZNeS0jdDiixE96NJmMaxgwusjLEItAttwj6T8LwMBS2OOG+OJDdyVXLIGPTkZvrSKVLur+M0AgbGPAcdvBFi5BP7WoUT0TlPxLrRtDTV5jZQrwrO8kf3X2AM0BYWnecuJq/UslMTAg2NzBZE0EikW7GycPG6sZvf/QNA8td8tQJWDke6swsp8qJgDu+sjQp30qfi48+qrPpHJ09Bq72wZzI0lbvjbdqPJ4VkDAZnABKTBP0ta7TfLtRok6a5etLaOkfvAOvDM2Jc/mC/njRATdDHyOQS8jtXt0QKZjA50zFUV6pa/IRVIdChj3z2QejQlQvFH7ryrDz35khZBxdLp3RrDBFG5JxAOb4U+nb5r9EZmhRgphgrUvAM9EqGwo804OAgsPnxNqDZeI4F4mS/XCtkN+J1ovCEbAawsGWwNeNqlmFZ1jSOZtqPP/ZTYh2+ME1nNiuCzqjbX x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(39860400002)(136003)(346002)(366004)(6916009)(36756003)(38100700002)(478600001)(6512007)(2906002)(4326008)(86362001)(4744005)(53546011)(6506007)(33656002)(316002)(71200400001)(2616005)(5660300002)(66946007)(8936002)(66476007)(91956017)(66446008)(76116006)(66556008)(8676002)(26005)(186003)(64756008)(54906003)(122000001)(6486002)(38070700005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cWpadFJyNEU5V1ZObVJra1Q0MFVtbG9ZUUNvY2hBOHZYZmkrUGdvaEt4V1U1?= =?utf-8?B?OEY3SHBwSk50MjFrZnRJeGNxYmdXRG1vb1o4ZmVXQVR1ZHVvQzc4UVZscFZH?= =?utf-8?B?a25lbVpPenk4WnJDZDVEQnNDa0NxSTlyZGgvMjB4enpueWEya1AxcGUvQTdv?= =?utf-8?B?L2xkcFk3eGYrQzRPUnFLb0dwcnRVYnB5ZUJDZVF0OVZERGFGbXNYM0hZTjFY?= =?utf-8?B?NzVySDI2RGZCS3FONnJ6ay9TQ0wyMVQ0aTNzMlRVUlZhanhLR01IS3Vsd0Ja?= =?utf-8?B?OE50SEhzRnhxVGNmS0NtVWhDaGw1MEt1a2tBWlArU3h1TU1tUDhKNUFXU3Zo?= =?utf-8?B?eFErU1ZmRWtXSG1zRWhzSVlra002SHh2cGU5bzc1c2pGbjEwYlRLUHhEREZx?= =?utf-8?B?NmQxZWNDN2U4dHlwb3pMTFlYVlRSME4vZkdtcG1qUmM4N05zQU0wWmg0ZVR5?= =?utf-8?B?bXlhRVZlaEdPTG9USEZqSFU2anZrbjd4MTZLMGlSdlAyUDl5cyt0b3hZL1Bp?= =?utf-8?B?ckQycTVaSENFSkZySzJSUFlMVGNPMG82VnpVTDYrZ3RRNEdyV1A3Y3ErdHl1?= =?utf-8?B?WGRNc0VaT1ZuU05QQmJVNnB4bW5BVFcrV1RSS0hnbC85S0JPOUVjSlY0d0FV?= =?utf-8?B?dUtmYnhtNWFzQTUwdmdxcEtYeUFVejUybGVvSlZtMENrS1VzZHdjeERZSExw?= =?utf-8?B?aERxcnc1QUY1VEFjN2J6enFQd2g3ajhNcjI5TDVkOTZybTRUb3lxNERzazA0?= =?utf-8?B?aXc3dm1LZkh2Rm8yRWk3RkFGV1cvWjE1VmZrdk9oYlVObXhHQjQySHFybE55?= =?utf-8?B?MXFKOWI5dU1kY1VPTDQ4Um9LSjg1L2F5bzcrZHJOY0FJSWRDbmp5ancxanFy?= =?utf-8?B?TktHbHVyVGFOZENoR3ZOSkMycmZxc1YzOHVTLzFibnJmTGNNS2NGQVVVZ3Vn?= =?utf-8?B?bVgxMDRTZ0kxOFVlMHp5ZEhGTDJlUEZ1OG5XRlhQU0ljdk91NVRwcmR5Z3dN?= =?utf-8?B?SnBOV0lSM1VPakRFVUljemZvenhxOXBRZTlHQmlLeHh5cmpUWEpia0VPTjZu?= =?utf-8?B?dm1TMkN1ektDa1FiRXlzMDNnVlliYUdFenVGMmJRT2xuWEhkT1Q2dkErbk9t?= =?utf-8?B?TXV6V3VDR3JjZnBDYkNSL3E4VklnRStPUE5YOG5YWms3S1V6c2ppallhSndi?= =?utf-8?B?VWFTc0RnTk1sTUdGV25qWHFiWDBlVzFLdmtMVTVIQWw1dGJxdTRaTElFWjN3?= =?utf-8?B?MGN1ZnhqTUZOMC9EMUhqRnVZMFNmTm0wczNSOU9UaVQyUytEUGR3NnRnREZt?= =?utf-8?B?OVNmZElBSVN5WjJjc095bWxvUXhJN2llcWQ0cjF0NHpqTFVWTkN4YmptcnVT?= =?utf-8?B?SDBjcVAxSVhnYlpUamRSN2IyT0M1WnFETVAyM1RkSG04clBpMGVTNHVKb2U4?= =?utf-8?B?WndnWk5HL2ZpSExPK0lsVmxiRlpWeEtWQitKbUxGcUtKMThXSVdoaG1hYUpC?= =?utf-8?B?Mk1DNTlhMjYrWFdJbHV6N3FNS252RUZ0ZDVrTTRBVzNvUzUySnFyLzFmc2wr?= =?utf-8?B?WlBEc3BWM1BTVTBHSzF6Uzc3Y3NSZkcxSjBDY0NHbzQwdW91ZW92aDdkWVNr?= =?utf-8?B?RUZlZkZHWHFnd2Ezd2JhcTNQK0dzOHZEaUFBaUNTd25HZmI3RGxjWStERHRZ?= =?utf-8?B?eUdiZUpyREoveUM0dzJERHErSnVOYUpLbGRQRXB3WHNkY3J1Q3h0QW5UWGJk?= =?utf-8?B?T3p4UGUxZ3ByMEVoMGxwYXJmT1l2OXFiY1lVemRHeUplVmNvRXVTdFd6cFht?= =?utf-8?B?SGc1OGswaGVyV0dhU3hodz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9C0BE4FF09895C46BE54644D948D5088@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f6072d0e-3e90-4745-b5fa-08d9513b4946 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 20:15:32.2297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mf+7wRZIBEiKmzVh3K+st6j47wdZqPiYN1zoIg7yxiosny8IHHtCW5XmfgXUou3H X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6046 X-Proofpoint-ORIG-GUID: gutV9f-3uTSMGVn-CBllkzxEixUW4kbC X-Proofpoint-GUID: gutV9f-3uTSMGVn-CBllkzxEixUW4kbC X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-27_13:2021-07-27, 2021-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 adultscore=0 mlxscore=0 priorityscore=1501 suspectscore=0 spamscore=0 clxscore=1015 mlxlogscore=713 impostorscore=0 lowpriorityscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107270118 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:16:13 -0000 VGhhbmtzLCBNYWhlc2guDQoNCj4gT24gSnVsIDI3LCAyMDIxLCBhdCAzOjUyIFBNLCBNYWhlc2gg SmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBUaGUg c3VyZ2VyeSB0aGF0IEkgcGVyZm9ybWVkIG9uIHRoZSBkcmFmdCwgYW5kIGNhbiBiZSBzZWVuIGlu IHRoZSBhdHRhY2hlZCBmaWxlcyBib3RoIGFzIGEgZGlmZiBhbmQgdGhlIGZ1bGwgZmlsZSB3YXMg dG8gcmVtb3ZlIHRoZSBtcGxzLXRlIG1vZHVsZSBkZXBlbmRlbmN5IGZyb20gdGhpcyBkcmFmdC4g V2Ugc2hvdWxkIHRoZXJlZm9yZSBhdCBsZWFzdCBub3QgYmUgZGVwZW5kZW50IG9uIHRoZSBpZXRm LXRlIG1vZHVsZS4NCg0KSSB0cmFja2VkIGRvd24gdGhlIGVhcmxpZXIgdGhyZWFkIHdpdGggdGhl IFJGQyBFZGl0b3IgYW5kIGZvbGxvd2VkIHVwIHRoZXJlLiANCg0KUmVnYXJkcywNCg0K4oCUSm9o bg0KDQo=