From nobody Thu Aug  2 04:48:14 2018
Return-Path: <c@tix.at>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7977A130E39 for <idr@ietfa.amsl.com>; Thu,  2 Aug 2018 04:48:13 -0700 (PDT)
X-Quarantine-ID: <kS9q-00UGDhO>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): X-Spam-Report: ... time (due to vacations, \342\200\246).\n\t[...] \n\tC[...]
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, HTML_MESSAGE=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 kS9q-00UGDhO for <idr@ietfa.amsl.com>; Thu,  2 Aug 2018 04:48:09 -0700 (PDT)
Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55AB130E2D for <idr@ietf.org>; Thu,  2 Aug 2018 04:48:08 -0700 (PDT)
Received: from 213-225-34-206.nat.highway.a1.net ([213.225.34.206] helo=[192.168.43.10]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <c@tix.at>) id 1flBj1-00065r-2b; Thu, 02 Aug 2018 13:25:00 +0200
From: Christoph Loibl <c@tix.at>
Message-Id: <B58908A0-0946-4610-B2AE-FC2729239C95@tix.at>
Content-Type: multipart/signed; boundary="Apple-Mail=_C5DF76F8-5CE4-4A68-80AA-28BC64753007"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 2 Aug 2018 13:48:02 +0200
In-Reply-To: <20180712185855.GQ12853@pfrc.org>
Cc: idr@ietf.org
To: Jeffrey Haas <jhaas@pfrc.org>
References: <20180712185855.GQ12853@pfrc.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/tYAZrw1c1g1uyEiHHGqJQOKiSBs>
Subject: Re: [Idr] Feedback on 5575-bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2018 11:48:13 -0000

--Apple-Mail=_C5DF76F8-5CE4-4A68-80AA-28BC64753007
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1E550494-10A8-46FE-9BB1-A33765BCC449"


--Apple-Mail=_1E550494-10A8-46FE-9BB1-A33765BCC449
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Jeff and IDR,

Thanks for your very detailed review of the draft. It is a very valuable =
piece of work. We already started working on this =
(identifying/categorising issues, preparing possible solutions for the =
list). This will unfortunately still take some time (due to vacations, =
=E2=80=A6).

One of our goals for the -bis is that we do *not* want to break the =
implemenations of RFC5575 with the -bis revision. Even if we keep that =
in mind, quite a few issues you pointed out can be resolved very easily, =
since the implementations already seem to agree on many points, even =
though it is left open by the RFC5575 and this agreement seems to be =
based on assumptions.

While I promise that we will send a complete report on all the issues =
pointed out to the list, I want to start/continue a discussion on =
extensibility of Flow Spec and possible options to open the door for =
future (and already pending in the queue) FS extensions in the -bis =
without breaking anything already out there:


> On 12.07.2018, at 20:58, Jeffrey Haas <jhaas@pfrc.org> wrote:
> This issue in validation, as I tersely noted in a prior IDR thread, =
really
> needs discussion in the document.  It impacts the ability to verify, =
to add
> new component types, and potentially cause invalid NLRI to propagate
> downstream.
>=20
> :   The <type, value> encoding is chosen in order to allow for future
> :   extensibility.
>=20
> It should be mentioned that due to the property above that extensions =
are
> problematic.

1) How can BGP possibly verify the correct structure of the FS NLRI, and =
does it need to?

cited from RFC5575:
BGP itself treats the NLRI as an opaque key to an entry in its
   databases.  Entries that are placed in the Loc-RIB are then
   associated with a given set of semantics, which is application
   dependent.

This is fundamental to the protocol and I do not think that changing =
this in the -bis is a very good idea (however, I am aware that not all =
implementations actually comply to the standard in this particular =
manner - see the next paragraph why this may be the case). What was also =
pointed out - as a resulting drawback - on the list, is that garbage =
gets propagated over the entire FS domain (as with any other opaque =
attribute).

However, there is a weird thing to note about the =E2=80=9Copacity=E2=80=9D=
 of FS NLRI: When it comes to validation (section 6 of RFC5575; this is =
where we check the NLRI dst-ip component against the unicast-routing) =
the NLRI seems *less* opaque. Actually BGP *needs* to decode the FS NLRI =
to some certain degree, otherwise it is unable to perform the validation =
(needed for accepting and propagating the prefix). However, it needs to =
be pointed out that even if there are unknown FS components in the NLRI, =
decoding the dst-ip will always work fine, since the components MUST be =
sorted by the type in ascending order (thus the dst-ip component is =
always the first! As long as there is no new type=3D0 component =
introduced this should be fine -> ToDo: add to IANA section to reserve =
type=3D0 component!)

I still favour to some degree the "opaque key=E2=80=9D property because =
this way we make sure that =E2=80=9Cre-encoding=E2=80=9D does not =
happen, and the encoding of the NLRI is consistent over the entire FS =
domain. Recoding (decode -> store -> encode -> propagate) of the NLRI =
means that BGP may generate ghost versions of FS NLRIs because they =
choose a different encoding on propagation (like you (Jeff) asked =
=E2=80=9Cshall we reorder the FS components=E2=80=9D -> I do not think =
so, because that potentially creates a ghost NLRI - if it is incorrect =
we can still treat it as withdraw (given we even more relax the *opaque* =
property of the protocol (what I am not so much on favour of)).


2) Now to the extensibility:

If BGP does not decode the NLRI further than to the type=3D1 (dst-ip) =
component(**) (which needs to appear in the first place anyway) we are =
fine. BGP can decode what it needs to and propagate it along with the =
rest of the (potentially) garbage NLRI to its peers (as it should do now =
- according to the specs). If we still want to verify even unknown FS =
components to some certain degree (while being compatible with the =
current specification RFC 5575 - and having an upgrade path) I would =
propose something like this:

If an unknown component type (not specified by this document) is =
encountered, the following encoding should be assumed:

<type (1 octet), length (2 octet), data (length octets)>

Future Flow Specification extensions MUST implement the above component =
encoding. If a unknown component is encountered, this prefix cannot be =
used for traffic filtering purposes (but MUST still be taken into =
account for BGP propagation). If a component type is known by the =
implementation but its length is set to 0 this component always =
evaluates to true.

Something along these lines may gracefully allow extensions while not =
breaking anything out there right from the start. It also gives BGP the =
ability to verify the NLRI to some certain degree. Additionally the =
length=3D0 case may allow to select rules that are not actually making =
use of a new component, but should only be applied if the implementation =
implements this particular extension.

note(**): should we put into the -bis that verification always fails if =
there is _no_ type=3D1 component in the NLRI? Or should we assume =
0.0.0.0/0 as dst-ip during verification?


I am aware that this may be a lengthy discussion, however please bear =
the following in mind:

This discussion is *not* about a possible Flow Spec 2.0! We want to =
retain compatibility to RFC 5575. We want to specify what is currently =
mostly based on assumptions by the different implementations. We want to =
eliminate inconsistencies and enhance extensibility if possible. And we =
want to get it right on the second try :-)

Please let us think along those lines in the discussion.

This is also why I think that your (Jeff) review is very valuable to the =
quality of this -bis draft. It will definitely help to eliminate quite a =
few uncertainties still left over from the current standards document.

Christoph

--
Christoph Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at


--Apple-Mail=_1E550494-10A8-46FE-9BB1-A33765BCC449
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi =
Jeff and IDR,<div class=3D""><br class=3D""></div><div class=3D"">Thanks =
for your very detailed review of the draft. It is a very valuable piece =
of work. We already started working on this (identifying/categorising =
issues, preparing possible solutions for the list). This will =
unfortunately still take some time (due to vacations, =E2=80=A6).</div><di=
v class=3D""><br class=3D""></div><div class=3D"">One of our goals for =
the -bis is that we do *not* want to break the implemenations of RFC5575 =
with the -bis revision. Even if we keep that in mind, quite a few issues =
you pointed out can be resolved very easily, since the implementations =
already seem to agree on many points, even though it is left open by the =
RFC5575 and this agreement seems to be based on assumptions.</div><div =
class=3D""><br class=3D""></div><div class=3D"">While I promise that we =
will send a complete report on all the issues pointed out to the list, I =
want to start/continue a discussion on extensibility of Flow Spec and =
possible options to open the door for future (and already pending in the =
queue) FS extensions in the -bis without breaking anything already out =
there:</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D""><div class=3D""></div></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D"">On 12.07.2018, =
at 20:58, Jeffrey Haas &lt;<a href=3D"mailto:jhaas@pfrc.org" =
class=3D"">jhaas@pfrc.org</a>&gt; wrote:</div><div class=3D"">This issue =
in validation, as I tersely noted in a prior IDR thread, really<br =
class=3D"">needs discussion in the document. &nbsp;It impacts the =
ability to verify, to add<br class=3D"">new component types, and =
potentially cause invalid NLRI to propagate<br class=3D"">downstream.<br =
class=3D""><br class=3D"">: &nbsp;&nbsp;The &lt;type, value&gt; encoding =
is chosen in order to allow for future<br class=3D"">: =
&nbsp;&nbsp;extensibility.<br class=3D""><br class=3D"">It should be =
mentioned that due to the property above that extensions are<br =
class=3D"">problematic.<br class=3D""></div></div></blockquote><div =
class=3D""><br class=3D""></div><div class=3D"">1) How can BGP possibly =
verify the correct structure of the FS NLRI, and does it need =
to?&nbsp;</div><div class=3D""><br class=3D""></div><div class=3D"">cited =
from RFC5575:</div><div class=3D""><pre class=3D"newpage" =
style=3D"font-size: 13.3333px; margin-top: 0px; margin-bottom: 0px; =
break-before: page; font-variant-ligatures: normal; orphans: 2; widows: =
2;">BGP itself treats the NLRI as an opaque key to an entry in its
   databases.  Entries that are placed in the Loc-RIB are then
   associated with a given set of semantics, which is application
   dependent. </pre><div class=3D""><br class=3D""></div></div><div =
class=3D"">This is fundamental to the protocol and I do not think that =
changing this in the -bis is a very good idea (however, I am aware that =
not all implementations actually comply to the standard in this =
particular manner - see the next paragraph why this may be the case). =
What was also pointed out - as a resulting drawback - on the list, is =
that garbage gets propagated over the entire FS domain (as with any =
other opaque attribute).</div><div class=3D""><br class=3D""></div><div =
class=3D"">However, there is a weird thing to note about the =
=E2=80=9Copacity=E2=80=9D of FS NLRI: When it comes to validation =
(section 6 of RFC5575; this is where we check the NLRI dst-ip component =
against the unicast-routing) the NLRI seems *less* opaque. Actually BGP =
*needs* to decode the FS NLRI to some certain degree, otherwise it is =
unable to perform the validation (needed for accepting and propagating =
the prefix). However, it needs to be pointed out that even if there are =
unknown FS components in the NLRI, decoding the dst-ip will always work =
fine, since the components MUST be sorted by the type in ascending order =
(thus the dst-ip component is always the first! As long as there is no =
new type=3D0 component introduced this should be fine -&gt; ToDo: add to =
IANA section to reserve type=3D0 component!)</div><div class=3D""><br =
class=3D""></div><div class=3D"">I still favour to some degree the =
"opaque key=E2=80=9D property because this way we make sure that =
=E2=80=9Cre-encoding=E2=80=9D does not happen, and the encoding of the =
NLRI is consistent over the entire FS domain. Recoding (decode -&gt; =
store -&gt; encode -&gt; propagate) of the NLRI means that BGP may =
generate ghost versions of FS NLRIs because they choose a different =
encoding on propagation (like you (Jeff) asked =E2=80=9Cshall we reorder =
the FS components=E2=80=9D -&gt; I do not think so, because that =
potentially creates a ghost NLRI - if it is incorrect we can still treat =
it as withdraw (given we even more relax the *opaque* property of the =
protocol (what I am not so much on favour of)).</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">2) =
Now to the extensibility:</div><div class=3D""><br class=3D""></div><div =
class=3D"">If BGP does not decode the NLRI further than to the type=3D1 =
(dst-ip) component(**) (which needs to appear in the first place anyway) =
we are fine. BGP can decode what it needs to and propagate it along with =
the rest of the (potentially) garbage NLRI to its peers (as it should do =
now - according to the specs). If we still want to verify even unknown =
FS components to some certain degree (while being compatible with the =
current specification RFC 5575 - and having an upgrade path) I would =
propose something like this:</div><div class=3D""><br =
class=3D""></div><div class=3D""><span =
id=3D"docs-internal-guid-9aa20fb4-fa2b-1b64-f9d4-b9ad5192d1f3" =
class=3D""><div style=3D"line-height: 1.38; margin-top: 0pt; =
margin-bottom: 0pt;" class=3D""><span style=3D"font-size: 8.5pt; =
font-family: &quot;Courier New&quot;; font-weight: 700; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;" class=3D"">If an unknown component type (not specified by =
this document) is encountered, the following encoding should be =
assumed:</span></div><br class=3D""><div style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;" class=3D""><span style=3D"font-size:=
 8.5pt; font-family: &quot;Courier New&quot;; font-weight: 700; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;" class=3D"">&lt;type (1 octet), length (2 octet), data (length =
octets)&gt;</span></div><br class=3D""><div style=3D"line-height: 1.38; =
margin-top: 0pt; margin-bottom: 0pt;" class=3D""><span style=3D"font-size:=
 8.5pt; font-family: &quot;Courier New&quot;; font-weight: 700; =
font-variant-ligatures: normal; font-variant-east-asian: normal; =
font-variant-position: normal; vertical-align: baseline; white-space: =
pre-wrap;" class=3D"">Future Flow Specification extensions MUST =
implement the above component encoding. If a unknown component is =
encountered, this prefix cannot be used for traffic filtering purposes =
(but MUST still be taken into account for BGP propagation). If a =
component type is known by the implementation but its length is set to 0 =
this component always evaluates to true.   </span></div><div =
class=3D""><span style=3D"font-size: 8.5pt; font-family: &quot;Courier =
New&quot;; font-weight: 700; font-variant-ligatures: normal; =
font-variant-east-asian: normal; font-variant-position: normal; =
vertical-align: baseline; white-space: pre-wrap;" class=3D""><br =
class=3D""></span></div></span></div><div class=3D"">Something along =
these lines may gracefully allow extensions while not breaking anything =
out there right from the start. It also gives BGP the ability to verify =
the NLRI to some certain degree. Additionally the length=3D0 case may =
allow to select rules that are not actually making use of a new =
component, but should only be applied if the implementation implements =
this particular extension.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">note(**): should we put into the -bis =
that verification always fails if there is _no_ type=3D1 component in =
the NLRI? Or should we assume 0.0.0.0/0 as dst-ip during =
verification?</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">I am aware that this may =
be a lengthy discussion, however please bear the following in =
mind:</div><div class=3D""><br class=3D""></div><div class=3D"">This =
discussion is *not* about a possible Flow Spec 2.0! We want to retain =
compatibility to RFC 5575. We want to specify what is currently mostly =
based on assumptions by the different implementations. We want to =
eliminate inconsistencies and enhance extensibility if possible. And we =
want to get it right on the second try :-)</div><div class=3D""><br =
class=3D""></div><div class=3D"">Please let us think along those lines =
in the discussion.</div><div class=3D""><br class=3D""></div><div =
class=3D"">This is also why I think that your (Jeff) review is very =
valuable to the quality of this -bis draft. It will definitely help to =
eliminate quite a few uncertainties still left over from the current =
standards document.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">Christoph</div><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D"">
<div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; orphans: auto; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; widows: =
auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;">--&nbsp;<br class=3D"">Christoph =
Loibl<br class=3D""><a href=3D"mailto:c@tix.at" =
class=3D"">c@tix.at</a>&nbsp;| CL8-RIPE | PGP-Key-ID:&nbsp;0x4B2C0055 =
|&nbsp;<a href=3D"http://www.nextlayer.at" =
class=3D"">http://www.nextlayer.at</a></div><div style=3D"color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><br =
class=3D""></div></div></div></body></html>=

--Apple-Mail=_1E550494-10A8-46FE-9BB1-A33765BCC449--

--Apple-Mail=_C5DF76F8-5CE4-4A68-80AA-28BC64753007
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQQ49wVNibKs7fQYJYbSbYynSywAVQUCW2LvcgAKCRDSbYynSywA
Va29AJ42RagLViKvSZpo6ycnUKXpdTr6JACdGdDy34Dk8ZPaEdFfgR4tsHkk44o=
=naif
-----END PGP SIGNATURE-----

--Apple-Mail=_C5DF76F8-5CE4-4A68-80AA-28BC64753007--


From nobody Mon Aug  6 08:17:52 2018
Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9580C129C6B; Mon,  6 Aug 2018 08:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 rT73ie9ZfxsA; Mon,  6 Aug 2018 08:17:41 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0A2128BAC; Mon,  6 Aug 2018 08:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17514; q=dns/txt; s=iport; t=1533568661; x=1534778261; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wc4RRHdT+a9Mo1eUTbMRsfO/XdxSEnmYz3niMfBkrWc=; b=X2CwQ0dwk2iiW0qr20z2YWy2IGYP0WfDhreq64jRyWfn2KYYQ04f6Fyi A0hheMPjyREgwkhYRAixDFtkh5fMwhBa5C7WchG5U7acvNdLsy/c9QZ0F 0xWxkEuVedqVU8lIi7msPjlHECuvustuIhXgAal4MXBz6VfkC3W/MaazX E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAgCrZWhb/4sNJK1GFhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDToFiKAqDdJRQgg13gkWFCo01gWYLhGwCF4MQITcVAQI?= =?us-ascii?q?BAQIBAQJtKIU3AQEBAQIBIxEzBA4MBAIBCBEBAwEBAQICBwoSAwICAh8RFAE?= =?us-ascii?q?CBggCBAENBRuDBYFoAw0IrBuBLocUDYMvgQtohE+BH4EoF4IAgRInH4IXNYJ?= =?us-ascii?q?WgWMDHyMHECMFgkIxgiQCjHKFLIdqKwkCiQaDL4MOgU2EIYJzhT+LQYZ2AhE?= =?us-ascii?q?UgSQzIoFScBU7KgGCPoIlBRKOF28BjnCBGwEB?=
X-IronPort-AV: E=Sophos;i="5.51,452,1526342400"; d="scan'208";a="153671802"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Aug 2018 15:17:40 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w76FHdTK021306 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Aug 2018 15:17:40 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 6 Aug 2018 11:17:39 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Mon, 6 Aug 2018 11:17:39 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Stewart Bryant <stewart.bryant@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "draft-templin-atn-bgp.all@ietf.org" <draft-templin-atn-bgp.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Thread-Topic: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
Thread-Index: AQHUIz7WGiRlD2ZlQkOPQ2ROmR01sA==
Date: Mon, 6 Aug 2018 15:17:39 +0000
Message-ID: <CE4A8029-1BDD-4DC3-8A87-2E51DD266D55@cisco.com>
References: <153243058668.22562.6511891462599952686@ietfa.amsl.com> <a6c05a6526184066bb0435131b8bfc54@XCH15-06-08.nw.nos.boeing.com> <7864a95d-754a-2bb9-d1b6-810202eeb0a7@gmail.com> <3a7ff55381db4adfa1b666356387a843@XCH15-06-08.nw.nos.boeing.com>
In-Reply-To: <3a7ff55381db4adfa1b666356387a843@XCH15-06-08.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: <681E0794AABE1644863062A0D6F16500@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4f-I1JJhyzPLATQG-qTJwpgxXkQ>
Subject: Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 15:17:44 -0000

SGkgU3Rld2FydCwgRnJlZCwgDQoNClNlZSBmdXJ0aGVyIHJlc3BvbnNlcyBiZWxvdy4NCg0K77u/
T24gNy8yNS8xOCwgNjoyMiBQTSwgIlRlbXBsaW4gKFVTKSwgRnJlZCBMIiA8RnJlZC5MLlRlbXBs
aW5AYm9laW5nLmNvbT4gd3JvdGU6DQoNCiAgICBIZWxsbyBTdGV3YXJ0LA0KICAgIA0KICAgIFNl
ZSBiZWxvdyBmb3IgZnVydGhlciBmb2xsb3ctdXA6DQogICAgDQogICAgVGhhbmtzIC0gRnJlZA0K
ICAgIA0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IFN0ZXdh
cnQgQnJ5YW50IFttYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tXQ0KICAgID4gU2VudDog
V2VkbmVzZGF5LCBKdWx5IDI1LCAyMDE4IDI6MTQgQU0NCiAgICA+IFRvOiBUZW1wbGluIChVUyks
IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHJ0Zy1kaXJAaWV0Zi5vcmcNCiAg
ICA+IENjOiBpZHJAaWV0Zi5vcmc7IHJ0Z3dnLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtdGVtcGxp
bi1hdG4tYmdwLmFsbEBpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgcnRnd2dAaWV0Zi5v
cmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbSWRyXSBSdGdkaXIgZWFybHkgcmV2aWV3IG9mIGRyYWZ0
LXRlbXBsaW4tYXRuLWJncC0wNw0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gT24gMjQv
MDcvMjAxOCAyMDo1MywgVGVtcGxpbiAoVVMpLCBGcmVkIEwgd3JvdGU6DQogICAgPiA+IEhlbGxv
IFN0ZXdhcnQsDQogICAgPiA+DQogICAgPiA+IFRoYW5rIHlvdSBmb3IgeW91ciBlZmZvcnQgaW4g
cmV2aWV3aW5nIHRoZSBkb2N1bWVudC4gUGxlYXNlIHNlZSBiZWxvdyBmb3INCiAgICA+ID4gZm9s
bG93LXVwIGRpc2N1c3Npb246DQogICAgPiA+DQogICAgPiA+IEZyZWQNCiAgICA+ID4NCiAgICA+
ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiA+PiBGcm9tOiBJZHIgW21haWx0
bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXdhcnQgQnJ5YW50DQogICAg
PiA+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDI0LCAyMDE4IDQ6MTAgQU0NCiAgICA+ID4+IFRvOiBy
dGctZGlyQGlldGYub3JnDQogICAgPiA+PiBDYzogaWRyQGlldGYub3JnOyBydGd3Zy1jaGFpcnNA
aWV0Zi5vcmc7IGRyYWZ0LXRlbXBsaW4tYXRuLWJncC5hbGxAaWV0Zi5vcmc7IGlkci1jaGFpcnNA
aWV0Zi5vcmc7IHJ0Z3dnQGlldGYub3JnDQogICAgPiA+PiBTdWJqZWN0OiBbSWRyXSBSdGdkaXIg
ZWFybHkgcmV2aWV3IG9mIGRyYWZ0LXRlbXBsaW4tYXRuLWJncC0wNw0KICAgID4gPj4NCiAgICA+
ID4+IFJldmlld2VyOiBTdGV3YXJ0IEJyeWFudA0KICAgID4gPj4gUmV2aWV3IHJlc3VsdDogSGFz
IElzc3Vlcw0KICAgID4gPj4NCiAgICA+ID4+IFRoaXMgaXMgYmFzaWNhbGx5IGEgd2VsbCB3cml0
dGVuIGRyYWZ0LCBhbHRob3VnaCBpdCBoYXMgaGFzIGEgbG90cyBvZiBzcGVsbGluZw0KICAgID4g
Pj4gbWlzdGFrZXMgYW5kIG5lZWRzIHRvIHBhc3NlZCB0aHJvdWdoIGEgc3BlbGwgY2hlY2tlciBi
ZWZvcmUgYSBmdXJ0aGVyIHZlcnNpb24NCiAgICA+ID4+IGlzIHVwbG9hZGVkLg0KICAgID4gPiBD
ZXJ0YWlubHkgd2Ugd2lsbCBmaXggdGhhdDsgYXBvbG9naWVzIGlmIGl0IGltcGFjdGVkIHRoZSBy
ZWFkYWJpbGl0eS4NCiAgICA+ID4NCiAgICA+ID4+IEhvd2V2ZXIsIEkgaGF2ZSBhIG51bWJlciBv
ZiBpc3N1ZXMgdGhhdCB0aGUgY2hhaXJzIGFuZCBhdXRob3JzIHNob3VsZCBjb25zaWRlcg0KICAg
ID4gPj4gYmVmb3JlIGRlY2lkaW5nIGhvdyB0byBwcm9jZWVkLg0KICAgID4gPj4NCiAgICA+ID4+
IFRoZSBmaXJzdCBxdWVzdGlvbiB0byBhc2sgaXMgd2hldGhlciB0aGUgd29yayBiZWxvbmdzIGlu
IFJUR1dHIG9yIGluIElEUiBzaW5jZQ0KICAgID4gPj4gd2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRo
ZSByZWZlcmVuY2UgdG8gIHRoZSBvcHRpbWl6YXRpb24gZGVzY3JpYmVkIGluDQogICAgPiA+PiBk
cmFmdC10ZW1wbGluLWFlcm9saW5rLTgyICB0aGlzIGlzIGEgcHVyZSBCR1Agc29sdXRpb24uIFRo
aXMgaXMgc29tZXRoaW5nIHRoYXQNCiAgICA+ID4+IHRoZSBSVEdXRyBjaGFpcnMgc2hvdWxkIGRp
c2N1c3Mgd2l0aCB0aGUgSURSIGNoYWlycy4gVGhleSBzaG91bGQgYWxzbyBkaXNjdXNzDQogICAg
PiA+PiB3aGV0aGVyIHRoZSBkcmFmdCBuZWVkcyB0byBiZSBsb29rZWQgYXQgYnkgYSBCR1Agc3Bl
Y2lhbGlzdCBiZWZvcmUgUlRHV0cgYWRvcHRzDQogICAgPiA+PiBpdC4NCiAgICA+ID4gVGhlIGRv
Y3VtZW50IGhhcyBiZWVuIHByZXNlbnRlZCBhdCBSVEdXRyBhdCB0aHJlZSBkaWZmZXJlbnQgSUVU
RiBtZWV0aW5ncw0KICAgID4gPiBub3cgYW5kIHNlZW1zIHRvIGhhdmUgYmVlbiB3ZWxsIHJlY2Vp
dmVkIHRoZXJlLiBTbywgd2Ugd291bGQgbGlrZSB0byBzZWUgaXQNCiAgICA+ID4gYmVjb21lIGFu
IFJUR1dHIHdvcmtpbmcgZ3JvdXAgaXRlbSBzbyB3ZSB3b3VsZCBub3QgaGF2ZSB0byBzdGFydCB0
aGUNCiAgICA+ID4gc29jaWFsaXphdGlvbiBwcm9jZXNzIG92ZXIgYWdhaW4sIGJ1dCB5b3VyIHBv
aW50IGlzIHdlbGwgdGFrZW4uIEkgZG8gbm90IGhhdmUNCiAgICA+ID4gZW5vdWdoIGV4cGVyaWVu
Y2Ugd2l0aCByb3V0aW5nIGFyZWEgd29ya2luZyBncm91cHMgdG8gdW5kZXJzdGFuZCBhbGwgb2YN
CiAgICA+ID4gdGhlIGltcGxpY2F0aW9ucywgc28gYW55IGd1aWRhbmNlIHdvdWxkIGJlIGFwcHJl
Y2lhdGVkLg0KICAgID4gDQogICAgPiBBY3R1YWxseSBpdCBtaWdodCBhbHNvIGJlIGEgY2FuZGlk
YXRlIGZvciBCRVNTIChCR1AgZW5hYmxlZCBzZXJ2aWNlcykuDQogICAgPiANCiAgICA+IFRoaXMg
aXMgYSBjaGFpci9BRCBkZWNpc2lvbiBhcyBtdWNoIGFzIGFueXRoaW5nLCBhbmQgdGhleSBhcmUg
bm9ybWFsbHkNCiAgICA+IGd1aWRlZCBieSB3aGVyZQ0KICAgID4gdGhlIHJlcXVpcmVkIGV4cGVy
dGlzZSBpcy4NCiAgICANCiAgICBKZWZmIFRhbnRzdXJhIHBvc3RlZCBhIG1lc3NhZ2Ugb24gdGhp
cyBzdWJqZWN0IHRoYXQgSSB3aWxsIGRlZmVyIHRvLg0KDQpXZSBhY3R1YWxseSBkaWQgZGlzY3Vz
cyB3aXRoIEdST1cgYW5kIHRoZSBjaGFpcnMgZmVsdCB0aGF0IHRoaXMgd2FzIGFuIG92ZXJsYXkg
bmV0d29yayB0aGF0IG1heSBvciBtYXkgbm90IGJlIHVzaW5nIHRoZSBnbG9iYWwgSW50ZXJuZXQg
YW5kLCBoZW5jZSwgbm90IHRoZSBwdXJ2aWV3IG9mIEdST1cuIA0KICAgIA0KICAgID4gPj4gVGhl
IGFwcHJvYWNoIG9mIGJ1aWxkaW5nIGFuIG92ZXJsYXkgdG8gc2VwYXJhdGUgdGhlIG5ldHdvcmsg
ZnJvbSB0aGUgbWFpbiBCR1ANCiAgICA+ID4+IHN5c3RlbSBpcyBhIHNvdW5kIG9uZSwgaW5kZWVk
IGZyb20gYm90aCB0aGUgbnVtYmVycyBhbmQgYSBzZWN1cml0eSBwb2ludCBvZg0KICAgID4gPj4g
dmlldywgaXQgd291bGQgYXBwZWFyIHRvIGJlICBlc3NlbnRpYWwgaW4gYSBzYWZldHkgY3JpdGlj
YWwgYXBwbGljYXRpb24gc3VjaCBhcw0KICAgID4gPj4gdGhpcy4gV2hhdCBib3RoZXJzIG1lIGlz
IHdoZXRoZXIgdGhlIGF1dGhvciBpcyB1bmRlcmVzdGltYXRpbmcgdGhlIHJpc2sgb2YNCiAgICA+
ID4+IHJ1bm5pbmcgYW4gYXBwbGljYXRpb24gc3VjaCBhcyB0aGlzIG92ZXIgdGhlIHB1YmxpYyBJ
bnRlcm5ldC4gV2hpbHN0IGFzIHRoZXkNCiAgICA+ID4+IGV4cGxhaW4gaW4gdGhlIHNlY3VyaXR5
IHNlY3Rpb24sIGhpZ2ggcHJvZmlsZSBjaXZpbCB1c2VycyBkbyB1bmRlcnN0YW5kIGhvdyB0bw0K
ICAgID4gPj4gbWl0aWdhdGUgcmlzayBhbmQgbWluaW1pemUgdGhlIGVmZmVjdCBvZiBhdHRhY2ss
IG5vbmUgb2YgdGhlc2Ugb3JnYW5pemF0aW9ucw0KICAgID4gPj4gYXJlIGFzIGxhcmdlIGEgdGFy
Z2V0IGFzIGNpdmlsIGF2aWF0aW9uIGZsaWdodCBzYWZldHksIGFuZCB0aHVzIEkgd291bGQgZXhw
ZWN0DQogICAgPiA+PiBjb25zaWRlcmFibGUgcmVzb3VyY2VzLCBldmVuIHRvIG5hdGlvbiBzdGF0
ZSBsZXZlbCwgdG8gYmUgZGlyZWN0ZWQgYXQgdGhlDQogICAgPiA+PiBhdHRhY2htZW50IHBvaW50
cy4gSG9wZWZ1bGx5IElDQU8gZnVsbHkgdW5kZXJzdGFuZHMgdGhlIHJpc2tzIGluIHJ1bm5pbmcg
dGhpcw0KICAgID4gPj4gb24gdGhlIHB1YmxpYyBJbnRlcm5ldCBhcyBwcm9wb3NlZC4gSWYgZXZl
ciB0aGVyZSB3ZXJlIGFuIGFwcGxpY2F0aW9uIGZvcg0KICAgID4gPj4gaW50ZXItZG9tYWluIG5l
dHdvcmsgc2xpY2luZywgdGhpcyBpcyBpdC4NCiAgICA+ID4gRm9yIGNpdmlsIGF2aWF0aW9uLCB0
aGlzIGlzIGluZGVlZCBhIGNyaXRpY2FsIGNvbnNpZGVyYXRpb24uIE9uIHRoZSBvcGVuIHB1Ymxp
Yw0KICAgID4gPiBJbnRlcm5ldCwgZm9yIGV4YW1wbGUsIGFsdGhvdWdoIElQc2VjIGNvdWxkIGJl
IHVzZWQgdG8gZXN0YWJsaXNoIHNlY3VyZQ0KICAgID4gPiB0dW5uZWxzIG90aGVyIHRocmVhdCB2
ZWN0b3JzIHN1Y2ggYXMgRERvUyBuZWVkIHRvIGJlIGNvbnNpZGVyZWQuIEluIG15DQogICAgPiA+
IHVuZGVyc3RhbmRpbmcsIElDQU8gaXMgdGhpbmtpbmcgYWJvdXQgYW4gdW5kZXJsYXkgbmV0d29y
ayBjb21wcmlzaW5nDQogICAgPiA+IHNlY3VyZWQgcGh5c2ljYWwgbGlua3MgKGUuZy4sIGZpYmVy
KSBhbmQvb3IgY29uc3RydWN0cyBsaWtlIFNELVdBTi4gQnV0LA0KICAgID4gPiB0aGUgY29uc3Ry
dWN0aW9uIG9mIHRoZSB1bmRlcmxheSBJIHRoaW5rIGlzIHNvbWV0aGluZyB0aGF0IGhhcyBiZWVu
DQogICAgPiA+IHRha2VuIGZvciBncmFudGVkIGFuZCBhcyB5b3Ugb2JzZXJ2ZSBpcyBwaXZvdGFs
IHRvIHRoZSBkZXNpZ24gc2VjdXJpdHkuDQogICAgPiBJbmRlZWQsIEkgd291bGQgaGF2ZSBleHBl
Y3RlZCB0aGlzIHRvIGJlIG9uIGEgc2VjdXJlIG5ldHdvcmsgb2Ygc29tZQ0KICAgID4gc29ydCBl
aXRoZXIgcHVyZWx5DQogICAgPiBwcml2YXRlIG9yIHNvbWUgZm9ybSBvZiBWUE4uIEhvd2V2ZXIs
IEkgYW0gc3VyZSBJIHJlYWQgaW4geW91ciB0ZXh0IHRoYXQNCiAgICA+IHlvdSB3ZXJlDQogICAg
PiBjb25zaWRlcmluZyB1c2luZyB0aGUgUHVibGljIEludGVybmV0IG11Y2ggaW4gdGhlIHdheSBv
ZiBTRC1XQU4uDQogICAgDQogICAgVGhpcyBpcyBhbiBhcmVhIHRoYXQgY291bGQgY2VydGFpbmx5
IHVzZSBtb3JlIGRpc2N1c3Npb24sIGFzIHdlIGhhdmUgYmVlbg0KICAgIHNlZWluZyBvbiB0aGUg
bGlzdC4gSXQgb2NjdXJzIHRvIG1lIHRoYXQsIGlmIGNyaXRpY2FsIHNlcnZpY2VzIGxpa2Ugb25s
aW5lIGJhbmtpbmcNCiAgICBjYW4gYmUgbWFkZSBzZWN1cmUgYW5kIHJvYnVzdCB3aGlsZSB1c2lu
ZyB0aGUgcHVibGljIEludGVybmV0IGFzIGFuDQogICAgdW5kZXJsYXksIHRoZW4gaXQgbWF5IGJl
IHRoYXQgY2FycnlpbmcgYWlyIHRyYWZmaWMgbWFuYWdlbWVudCBzZXJ2aWNlcyB2aWENCiAgICBz
ZWN1cmVkIHR1bm5lbHMgb3ZlciB0aGUgSW50ZXJuZXQgY2FuIGFsc28gYmUgcG9zc2libGUuIEZh
aWxpbmcgdGhhdCwgaXQNCiAgICBzZWVtcyBsaWtlIHRoZSBvbmx5IG90aGVyIG9wdGlvbiBpcyB0
byBydW4gZGVkaWNhdGVkIHByaXZhdGUgZmliZXJzIHdpdGgNCiAgICBubyBjb25uZWN0aW9ucyB0
byB0aGUgSW50ZXJuZXQgLSBvciBhcmUgdGhlcmUgb3RoZXIgbWV0aG9kcyBJIG1heSBiZQ0KICAg
IHVuYXdhcmUgb2Y/DQoNCldlIGhhdmUgZGVzY3JpYmVkIHRoZSBCR1Agb3ZlcmxheSBpbiB0aGlz
IGRyYWZ0IGFuZCBub3QgdGhlIHR1bm5lbGluZyB0ZWNobm9sb2d5IG9yIGhvdyB0aGUgc2VjdXJp
dHkgYXNzb2NpYXRpb25zIGFyZSBkaXNzZW1pbmF0ZWQuIFBlcmhhcHMsIHdlIHNob3VsZCBpbmRp
Y2F0ZSB0aGlzIGlzIG91dCBvZiBzY29wZSBhbmQgY29uc2lkZXIgd2hhdCBhdHRhY2tzIGNhbiBi
ZSBtYWRlIG9uIHRoZSBBVE4gQkdQIGNvbnRyb2wgcGxhbmUuIA0KICAgIA0KICAgID4gPj4gVGhl
cmUgaXMgYSBzdWdnZXN0aW9uIGluIHNlY3Rpb24gMyB0aGF0IGZvciByZWFzb25zIG9mIGNvc3Qs
IGdsb2JhbGx5IHVuaXF1ZQ0KICAgID4gPj4gQVNOcyB3b3VsZCBub3QgYmUgdXNlZC4gSXQgaXMg
ZGlmZmljdWx0IHRvIGJlbGlldmUgdGhhdCBjb3N0IGlzIGFuIGlzc3VlIGluIGFuDQogICAgPiA+
PiBTb0Ygc3lzdGVtLiBXaGF0IGlzIHN1cmVseSBuZWVkZWQgaXMgdGhlIG1vc3Qgcm9idXN0IGFw
cHJvYWNoLCB3aGljaCBpbiB0aGUNCiAgICA+ID4+IGxvbmcgdGVybSBpcyB1c3VhbGx5IHRoZSBj
aGVhcGVzdCBhbnl3YXkuIFVzaW5nIGdsb2JhbCBpZGVudGlmaWVycyBtaW5pbWl6ZXMNCiAgICA+
ID4+IHRoZSBwb3NzaWJpbGl0eSBvZiBlcnJvciBhbmQgaXNzdWVzIGlmIGV2ZXIgdGhlcmUgaXMg
YSByb3V0aW5nIGxlYWssIGFuZCB0aHVzDQogICAgPiA+PiB0aGUgZGVjaXNpb24gb24gd2hldGhl
ciB0byB1c2UgcHJpdmF0ZSBvciBnbG9iYWwgaWRlbnRpZmllcnMgbmVlZHMgc29tZSBjYXJlZnVs
DQogICAgPiA+PiB0aG91Z2h0IGJleW9uZCB0aGF0IGV4cHJlc3NlZCBpbiB0aGlzIHZlcnNpb24g
b2YgdGhlIGRyYWZ0Lg0KICAgID4gPiBJIGRvbid0IG1pbmQgZHJvcHBpbmcgdGhlIGFzc2VydGlv
biB0aGF0IHByaXZhdGUgQVMgbnVtYmVycyBjb3VsZCBiZSB1c2VkLg0KICAgID4gPiBBcyB5b3Ug
c2F5LCB0aGVyZSBpcyBwcm9iYWJseSBubyBkb3duc2lkZSB0byBwcm9jdXJpbmcgcmVhbCBnbG9i
YWwgQVMNCiAgICA+ID4gbnVtYmVycyB1cCBmcm9udCBldmVuIGlmIHRoZSBvdmVybGF5IGlzIG5l
dmVyIGNvbm5lY3RlZCB0byB0aGUgZ2xvYmFsDQogICAgPiA+IHB1YmxpYyBJbnRlcm5ldC4NCiAg
ICA+ID4NCiAgICA+ID4+IEkgYW0gd29ycmllZCBhYm91dCB0aGUgdGV4dCB0b3dhcmRzIHRoZSBl
bmQgb2Ygc2VjdGlvbiB0aHJlZSB3aGljaCBwcm9wb3Nlcw0KICAgID4gPj4gc3BsaXR0aW5nIHRo
ZSBuZXR3b3JrIGludG8gdHdvIG9yIG1vcmUgZGlzam9pbnQgc3lzdGVtcywgc2luY2UgdGhhdCB3
aWxsIHN1cmVseQ0KICAgID4gPj4gbGVhZCB0byBvcGVyYXRpb24gYW5kIGludGVncmF0aW9uIGlz
c3Vlcy4NCiAgICA+ID4gTG9va2luZyBhdCB0aGF0IHRleHQgd2l0aCBmcmVzaCBleWVzLCBJIGNh
biBzZWUgdGhhdCBhIHJld3JpdGUgd291bGQgaGVscA0KICAgID4gPiBicmluZyBhY3Jvc3MgdGhl
IHBvaW50IHdlIGFyZSB0cnlpbmcgdG8gbWFrZS4gV2hhdCB3ZSB3YW50IHRvIGhhdmUgaXMNCiAg
ICA+ID4gYSBtZWFucyBmb3Igc3VwcG9ydGluZyBtdWx0aXBsZSBpbmRlcGVuZGVudCBSSUJzIGFu
ZCBib3VuZGluZyB0aGUNCiAgICA+ID4gbnVtYmVycyBvZiBwcmVmaXhlcyBlYWNoIFJJQiB3aWxs
IGJlIHNpemVkIHRvIGNhcnJ5LiBTbywgaWYgZWFjaCBSSUINCiAgICA+ID4gc3VwcG9ydGVkIHVw
IHRvIDFNIHByZWZpeGVzIGFuZCB3ZSBoYWQgMUsgUklCcywgd2Ugd291bGQgYmUgYWJsZQ0KICAg
ID4gPiB0byBzZXJ2aWNlIDFCIHByZWZpeGVzIG9yIGV2ZW4gYSBiaXQgbW9yZS4gRG9lcyB0aGF0
IGhlbHAgY2xhcmlmeT8gSWYgc28sDQogICAgPiA+IEkgd2lsbCBjb25zdWx0IHdpdGggY28tYXV0
aG9ycyB0byBpbXByb3ZlIHRoYXQgdGV4dC4NCiAgICA+IA0KICAgID4gV293LCBhcmUgeW91IHN1
cmUgdGhhdCBzdWNoIGEgc3lzdGVtIGlzIGJ1aWxkYWJsZT8NCiAgICANCiAgICBJIGhhdmUgcHJv
dmVuIHRoYXQgYSBzaW5nbGUgc2V0IG9mIGNvcmUgQVNCUnMgY2FuIGNhcnJ5IDFNIEJHUCByb3V0
ZXMNCiAgICBldmVuIG9uIGxpZ2h0d2VpZ2h0IGxpbnV4IHZpcnR1YWwgbWFjaGluZXMgcnVubmlu
ZyBRdWFnZ2EuIEFuZCwgb25seQ0KICAgIGEgZmV3IGNBU0JScyAocGVyaGFwcyBhcyBtYW55IGFz
IDEwKSBuZWVkIHRvIGNhcnJ5IHRoZSBmdWxsIHJvdXRpbmcNCiAgICB0YWJsZS4gVGhlIHN0dWIg
QVNCUnMgb25seSBrZWVwIHRyYWNrIG9mIHRoZWlyIGFzc29jaWF0ZWQgQ2xpZW50cywgYW5kDQog
ICAgY29uZmlndXJlIGEgZGVmYXVsdCByb3V0ZSB3aXRoIGEgY0FTQlIgYXMgdGhlIG5leHQgaG9w
IGZvciBvdGhlciBwcmVmaXhlcy4NCiAgICBTbywgdGhpcyBpcyBhIHZlcnkgbGVhbmVkLWRvd24g
QkdQIHNlcnZpY2UgaW4gY29tcGFyaXNvbiB0byB0aGUgd2F5IEJHUA0KICAgIHdvcmtzIGluIHRo
ZSBnbG9iYWwgcHVibGljIEludGVybmV0Lg0KICAgIA0KICAgID4gV2hhdCB5b3Ugc2VlbSB0byBi
ZSBidWlsZGluZyBpcyBhIGh1Z2UgdW5hZ2dyZWdhdGVkIHJvdXRpbmcgc3lzdGVtLg0KICAgID4g
UGVvcGxlIGhhdmUgY29uc2lkZXJlZCB0aGF0IGJlZm9yZSBhbmQgZm91bmQgdGhhdCBpdCB3YXMN
CiAgICA+IHVuaW1wbGltZW50YXRibGUuIFJlbWVtYmVyIHRoYXQgZm9yIGV2ZXJ5IHVuYWdncmVn
YXRlZCBwcmVmaXggaW4gdGhlIFJJQg0KICAgID4geW91IG5lZWQgYW4gZW50cnkgaW4gdGhlIEZJ
Qi4gVGhlIEZJQiBpbiBhIGNvcmUgcm91dGVyIGlzIGhpZ2ggc3BlZWQNCiAgICA+IChleHBlbnNp
dmUpIG1lbW9yeSBhbmQgd2lsbCBiZSByZXBsaWNhdGVkIG9uIGV2ZXJ5IGxpbmUgY2FyZC4NCiAg
ICANCiAgICBJIGhhdmUgaW1wbGVtZW50ZWQgaXQsIGFuZCB0ZXN0ZWQgd2l0aCB1cCB0byAxTSB1
bmFnZ3JlZ2FlZCBwcmVmaXhlcy4NCiAgICBBbmQsIGFnYWluLCBvbmx5IGEgZmV3IG5vZGVzIHdv
dWxkIG5lZWQgdG8gbWFpbnRhaW4gYSBmdWxsIFJJQi9GSUIuDQogICAgDQogICAgUmVtZW1iZXIg
YWxzbyB0aGF0IHRoZSBnbG9iYWwgcHVibGljIEludGVybmV0IGhhcyBzb21lIDYwMEsgb3IgbW9y
ZQ0KICAgIHVuYWdncmVnYXRlZCBwcmVmaXhlcyBhbmQgc2VlbXMgdG8gc3RpbGwgYmUgZG9pbmcg
ZmluZSwgc28gdGhlcmUgaXMNCiAgICBwcmVjZWRlbmNlIGZvciBhIHNpbmdsZSBSSUIgc3VwcG9y
dGluZyBzdWNoIGxhcmdlIG51bWJlcnMuIFNvLCBpZiB3ZQ0KICAgIGRlcGxveSAxSyBpbmRlcGVu
ZGVudCBSSUJzIHRoZW4gb3VyIDFCIHRhcmdldCBzZWVtcyBmZWFzaWJsZS4NCiAgICANCiAgICA+
IEkgdGhpbmsgdGhhdCB5b3UgcmVhbGx5IG5lZWQgdG8gZGlzY3VzcyB5b3VyIHNjYWxpbmcgcmVx
dWlyZW1lbnRzIHdpdGgNCiAgICA+IHNvbWUgaGFyZHdhcmUNCiAgICA+IHZlbmRvcnMgdG8gdmVy
aWZ5IHRoYXQgdGhlIGRlc2lnbiB5b3UgcHJvcG9zZSBjYW4gc3VwcG9ydCB0aGUgcmVxdWlyZWQN
CiAgICA+IGFpcmNyYWZ0DQogICAgPiBwb3B1bGF0aW9uIG92ZXIgdGhlIGV4cGVjdGVkIGxpZmV0
aW1lIG9mIHRoZSBzeXN0ZW0uDQogICAgPiANCiAgICA+IFdoYXQgSSBzdXNwZWN0IHRoYXQgeW91
IG5lZWQgaXMgc29tZSBzb3J0IG9mIGZvcm1hbCBoaWVyYXJjaHkgb3INCiAgICA+IGxheWVyaW5n
IGluIHRoZSBzeXN0ZW0gdG8gc3VwcG9ydA0KICAgID4gbG9uZyB0ZXJtIHNjYWxpbmcsIGFuZCB0
aGF0IGlzIGdvaW5nIHRvIGJlIGEgbG90IGVhc2llciBpZiBpdCBpcw0KICAgID4gZXhwbGljaXRs
eSBkZXNpZ25lZCBpbiBvbiBkYXkgb25lLg0KICAgIA0KICAgIEkgdW5kZXJzdGFuZCB5b3VyIGNv
bmNlcm4sIGJ1dCBJIHRoaW5rIHdlIGFyZSBPSy4gQnV0LCBJIHdpbGwgYnJpbmcgdGhpcw0KICAg
IGRpc2N1c3Npb24gcG9pbnQgdXAgd2l0aCBjby1hdXRob3JzIHRvIG1ha2Ugc3VyZSB3ZSBhcmUg
aW4gYWdyZWVtZW50Lg0KDQpJIGFncmVlIGdpdmVuIHRoZSB1c2FnZSBhbmQgc2NvcGluZyBvZiBN
TlBzLiANCiAgICANCiAgICA+ID4+IEluIHNlY3Rpb24gNiBjb25zaWRlcmF0aW9uIGlzIGdpdmVu
IHRvIHNjYWxpbmcgdGhlIGNvcmUsIHdoaWNoIGxvb2tzIGJhc2ljYWxseQ0KICAgID4gPj4gdW5k
ZXIgY29udHJvbCBmb3IgdGhlIGV4aXN0aW5nIGZsaWdodCBwcm9maWxlLCBidXQgd2l0aCByZWxh
dGl2ZWx5IGxpdHRsZQ0KICAgID4gPj4gaGVhZHJvb20gZm9yIGV4cGFuc2lvbi4gIEdpdmVuIHRo
ZSByaXNlIGluIFVBVnMsIHRoYXQgd2lsbCBzdXJlbHkgbmVlZCB0byBiZQ0KICAgID4gPj4gaW50
ZWdyYXRlZCBpbnRvIGEgY29tbW9uIGZsaWdodCBzYWZldHkgc3lzdGVtLCBJIGFtIGNvbmNlcm5l
ZCBhcyB0byB3aGV0aGVyIHRoZQ0KICAgID4gPj4gYXV0aG9ycyBoYXZlIGFsbG93ZWQgc3VmZmlj
aWVudCByb29tIGZvciBleHBhbnNpb24uIEFnYWluIGhvcGVmdWxseSB0aGUgZmxpZ2h0DQogICAg
PiA+PiBzcGVjaWFsaXN0cyBoYXZlIHRha2VuIHRoaXMgaW50byBhY2NvdW50IGFuZCB0aGlzIGlz
IG5vdCBhIHByb2JsZW0uDQogICAgPiA+IFRoZSB1cHBlciBib3VuZCBpbiB0ZXJtcyBvZiBzY2Fs
aW5nIHdlIHdlcmUgdGFyZ2V0aW5nIHdhcyB1cCB0byAxQg0KICAgID4gPiBwcmVmaXhlcyBjYXJy
aWVkIGFzIEJHUCByb3V0ZXMgaW4gb3JkZXIgdG8gYWxsb3cgZm9yIGV4cGFuc2lvbi4gWW91IGFy
ZQ0KICAgID4gPiByaWdodCB0byBvYnNlcnZlIHRoYXQgd2UgYXJlIGF0IHRoZSBhZHZlbnQgb2Yg
d2lkZS1zY2FsZSBkZXBsb3ltZW50IG9mDQogICAgPiA+IFVBVnMsIGJ1dCB0aGlzIG5ldHdvcmsg
d291bGQgYmUgb25seSBmb3IgdGhvc2UgVUFWcyB0aGF0IGZseSB0bywgZnJvbQ0KICAgID4gPiBv
ciB0aHJvdWdoIGFpcnNwYWNlIGNvbnRyb2xsZWQgYnkgQWlyIFRyYWZmaWMgQ29udHJvbGxlcnMg
KEFUQ3MpIC0gbWVhbmluZw0KICAgID4gPiBpdCB3b3VsZCBvbmx5IGJlIGZvciBVQVZzIHRoYXQg
dGFrZSBvZmYgYW5kIGxhbmQgYXQgYWlycG9ydHMuDQogICAgPiBXZWxsLCB5b3UgYXJlIHRoZSBh
cHBsaWNhdGlvbiBleHBlcnQgaGVyZSwgYnV0IHRoYXQgc2VlbXMgdG8gYmUgYQ0KICAgID4gY3Jp
dGljYWwgYXNzdW1wdGlvbg0KICAgID4gdGhhdCB5b3UgbmVlZCB0byB0ZXN0IGluIG11bHRpcGxl
IGdlb2dyYXBoaWVzLiBUaGlua2luZyBhYm91dCB0aGUgTG9uZG9uDQogICAgPiBhaXJwb3J0cywg
dGhhdA0KICAgID4gaXMgcXVpdGUgYSByZXN0cmljdGlvbi4NCiAgICANCiAgICBJdCBpcyB0cnVl
IHRoYXQgdGhlcmUgYXJlIGxvdHMgb2YgYWlycGxhbmVzIG91dCB0aGVyZSwgYnV0IHByb2JhYmx5
IG5vdCBhcyBtYW55DQogICAgYXMgbW9zdCBwZW9wbGUgdGhpbmsuIEkgdGhpbmsgdGhlIG51bWJl
cnMgb2YgYWlycGxhbmVzIGRlcGxveWVkIHdvcmxkd2lkZQ0KICAgIGlzIG9uIHRoZSBvcmRlciBv
ZiAxMF40IC0gMTBeNSAtIG5vdCBtaWxsaW9ucyB1cG9uIG1pbGxpb25zLiBTbywgSSB0aGluayB3
ZQ0KICAgIGNvdWxkIGxpdmUgd2l0aCBhIHN5c3RlbSB0aGF0IHNjYWxlcyB1cCB0byAxQiB1bmFn
Z3JlZ2F0ZWQgcHJlZml4ZXMgZm9yDQogICAgYSBsb25nIHRpbWUuIA0KDQpJICBhZ3JlZSBhbmQg
dGhlIHNjYWxlIHdpbGwgYmUgaW4gdGhlIG1pbGxpb25zIGZvciB0aGUgc29tZSB0aW1lIHRvIGNv
bWUuIA0KDQpUaGFua3MsDQpBY2VlDQoNCiAgICANCiAgICA+ID4gRm9yIHRoZSBmdXR1cmUsDQog
ICAgPiA+IHRoZSB0eXBlcyBvZiBVQVZzIHRoYXQgd2lsbCBldmVudHVhbGx5IGRvIHRoYXQgaW5j
bHVkZSB1bm1hbm5lZCBjYXJnbw0KICAgID4gPiBkZWxpdmVyeSBmcmVpZ2h0ZXJzIGFuZCB0aGUg
bGlrZS4gQnV0LCB3ZSB3b3VsZCBvbmx5IGJlIGV4cGVjdGluZyBhIGZldw0KICAgID4gPiB0aG91
c2FuZHMsIHRlbi10aG91c2FuZHMsIG9yIGh1bmRyZWQtdGhvdXNhbnNkcyBvZiB0aG9zZTsgY2Vy
dGFpbmx5DQogICAgPiA+IG5vdCBtaWxsaW9ucyBhbmQgbWlsbGlvbnMuDQogICAgPiBJIGFtIGFs
d2F5cyByZW1pbmRlZCB0aGF0IHdoZW4gSVB2NCB3YXMgZGVzaWduZWQsIGFuZCAoaW4gbXVjaCB0
aGUgc2FtZQ0KICAgID4gZXJhIEV0aGVybmV0KQ0KICAgID4gdGhlaXIgYWRkcmVzcyBzaXplcyB3
ZXJlIGFuIGFwcHJveGltYXRpb24gdG8gaW5maW5pdHkuIFRoZXkgYXJlIG5vdyBhDQogICAgPiBs
b25nIHdheSBmcm9tIGluZmluaXR5Lg0KICAgID4gVGhpcyB3aWxsIGJlIGFuIGV4cGVuc2l2ZSBz
eXN0ZW0gdG8gcmVwbGFjZSBzbyBpdCBuZWVkcyBtaWdyYXRpb24gcGF0aA0KICAgID4gdG8gaXRz
IGluZmluaXR5Lg0KICAgIA0KICAgIEl0IGlzIGEgZ29vZCBwb2ludCwgYnV0IHVwIHRvIDFCIHVu
YWdncmVnYWVkIHByZWZpeGVzIGFscmVhZHkgc2VlbXMgcHJldHR5DQogICAgcm9idXN0IGZvciBz
dGF0ZSBvZiB0aGUgYXJ0IGR5bmFtaWMgcm91dGluZyBwcm90b2NvbHMuIFNvLCB0byBnbyB0byBz
b21ldGhpbmcNCiAgICB0aGF0IHN1cHBvcnRzIGV2ZW4gZ3JlYXRlciBzY2FsaW5nIHdvdWxkIHJl
cXVpcmUgZWl0aGVyIGV4dGVuZGluZyBvdXIgQkdQDQogICAgYmFzZWQgYXJjaGl0ZWN0dXJlIChl
LmcuLCBieSBhZGRpbmcgYW5vdGhlciB0aWVyIGluIHRoZSBoaWVyYXJjaHkpIG9yIGludHJvZHVj
aW5nDQogICAgYSBuZXcgYXJjaGl0ZWN0dXJlIHRoYXQgc2NhbGVzIGluIGEgc2ltaWxhciBmYXNo
aW9uIGFzIHRoZSBnbG9iYWwgRE5TLiANCiAgICANCiAgICA+ID4gRm9yIHNtYWxsIFVBVnMgdGhh
dCBzdGF5IGF3YXkgZnJvbSB0aGUgYWlycG9ydHMsIGhvd2V2ZXIsIHRoZXJlIGlzDQogICAgPiA+
IHBvdGVudGlhbCBmb3IgbWFueSBtaWxsaW9ucyBvZiB0aG9zZSBvciBtb3JlLiBGb3IgdGhlbSwg
dGhlIEZBQSBhbmQNCiAgICA+ID4gTkFTQSBoYXZlIGEgY29uY2VwdCBrbm93biBhcyAiVW5tYW5u
ZWQgKGFpcikgVHJhZmZpYyBNYW5hZ2VtZW50Ig0KICAgID4gPiBvciAiVVRNIi4gVGhlIFVUTSB3
b3VsZCBuZWVkIHRvIGJlIGEgc2VwYXJhdGUgbmV0d29yayB1bnRvIGl0c2VsZiwNCiAgICA+ID4g
YnV0IHdlIGJlbGlldmUgdGhlc2Ugc2FtZSBCR1AgcHJpbmNpcGxlcyBjb3VsZCBhcHBseSB0aGVy
ZS4NCiAgICA+ID4NCiAgICA+IA0KICAgID4gQmVzdCByZWdhcmRzDQogICAgPiANCiAgICA+IFN0
ZXdhcnQNCiAgICA+IA0KICAgIA0KICAgIA0KDQo=


From nobody Mon Aug  6 09:20:57 2018
Return-Path: <stewart.bryant@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6CA130E59; Mon,  6 Aug 2018 09:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vQqvvFT3PVdm; Mon,  6 Aug 2018 09:20:52 -0700 (PDT)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 4CB20130E0F; Mon,  6 Aug 2018 09:20:52 -0700 (PDT)
Received: by mail-wr1-x435.google.com with SMTP id j5-v6so12919419wrr.8; Mon, 06 Aug 2018 09:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=pI+bIe1UtkEMA3qgiGw2T5X39wrxLhzI+5SfVdbRYnA=; b=DB6uo5a8dRa6j7YpO4wHUh78ckn5XPlV1EilWNkk+ERLmw0cTCOWU5ndgONVnbFiwG +1IjcnREji1rL6CZ6I+hsH288ipo+YcFm5RYrkl6g1rqLRm5Ap95hZE4HSZEuZSF6dY+ rTYfSHdZWNP465xR6mIWjtRbr1mQjswS8LFow7z5/f309uAL1+tN9nAv9MBMtfF/g63U dDphGlG1QQ6IAYVfSj2A0hh4N526f1+zpZyuah5ouYWXMJ3SYnHPovZdEhjYaG8i+q8R Xw+2CEvfV8wBw3vqa5o4p+9YaMpg8zm6EL96naKuahuulqMPffLSdvyp3lYh1mrfWSaP mQmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pI+bIe1UtkEMA3qgiGw2T5X39wrxLhzI+5SfVdbRYnA=; b=lj9abIbaz203Od+iFQsHO7rP+c/7ShrL+vOG22sbYcAY7a5DViiZJiMSX7a2j/RGQU x5kTOc+ZOLDNbQsl4YRC0ZnW03rXJQ48ky6sxrNviNMe+VKbx3h44LIOE9FX4ZJqrbfH jbQ5YvFH4xiP9sr9Lk2m0Cd+bLeoYJHGkzY5lXojodO+XvcMYDfR7381kLKgJIMcxxEP fDH4zyWlVYEsv5ZOi4JzjqmMIGANB4PAmDH5g+KrRdtRvGHGfTyMilYefdO8WX5RZOws mlH3ladMd4p1DMxNJjZ/xrc6mibsUNzEzN7q+C3/AzO97zXqqmaMbE+QXTgt7Z3L+ZBV brOg==
X-Gm-Message-State: AOUpUlH0Iwy7KDSbBALuonRS6Xn1Rmq8hpiJfoAFz2lJVoBxMGUL/DBv AmiIkbqbDo6DPxFAxNIKOc5wqnB8
X-Google-Smtp-Source: AAOMgpdRGNUbMspeOhCweycwWNTc7MAycAIsXrC2xZnjQ/9Hq7IDTqJ6nl1KT2E+39vkottQiN+RFQ==
X-Received: by 2002:adf:8325:: with SMTP id 34-v6mr9890786wrd.67.1533572450414;  Mon, 06 Aug 2018 09:20:50 -0700 (PDT)
Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id t6-v6sm8729248wmf.8.2018.08.06.09.20.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 09:20:49 -0700 (PDT)
To: "Acee Lindem (acee)" <acee@cisco.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Cc: "idr@ietf.org" <idr@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "draft-templin-atn-bgp.all@ietf.org" <draft-templin-atn-bgp.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <153243058668.22562.6511891462599952686@ietfa.amsl.com> <a6c05a6526184066bb0435131b8bfc54@XCH15-06-08.nw.nos.boeing.com> <7864a95d-754a-2bb9-d1b6-810202eeb0a7@gmail.com> <3a7ff55381db4adfa1b666356387a843@XCH15-06-08.nw.nos.boeing.com> <CE4A8029-1BDD-4DC3-8A87-2E51DD266D55@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <158c71b6-28b4-3724-13ac-cc271fd4e0f2@gmail.com>
Date: Mon, 6 Aug 2018 17:20:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CE4A8029-1BDD-4DC3-8A87-2E51DD266D55@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fp5ZJQQ2bR3_TYZZqxwq3JKHnH8>
Subject: Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 16:20:55 -0000

Sounds like you are on top of the scaling issues.

Thanks for the reply. At some time you might want to put in some more 
text to stop the question coming up again, as I am sure it will for 
example during IESG review.

- Stewart

On 06/08/2018 16:17, Acee Lindem (acee) wrote:
> Hi Stewart, Fred,
>
> See further responses below.
>
> On 7/25/18, 6:22 PM, "Templin (US), Fred L" <Fred.L.Templin@boeing.com> wrote:
>
>      Hello Stewart,
>      
>      See below for further follow-up:
>      
>      Thanks - Fred
>      
>      > -----Original Message-----
>      > From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
>      > Sent: Wednesday, July 25, 2018 2:14 AM
>      > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; rtg-dir@ietf.org
>      > Cc: idr@ietf.org; rtgwg-chairs@ietf.org; draft-templin-atn-bgp.all@ietf.org; idr-chairs@ietf.org; rtgwg@ietf.org
>      > Subject: Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
>      >
>      >
>      >
>      > On 24/07/2018 20:53, Templin (US), Fred L wrote:
>      > > Hello Stewart,
>      > >
>      > > Thank you for your effort in reviewing the document. Please see below for
>      > > follow-up discussion:
>      > >
>      > > Fred
>      > >
>      > >> -----Original Message-----
>      > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stewart Bryant
>      > >> Sent: Tuesday, July 24, 2018 4:10 AM
>      > >> To: rtg-dir@ietf.org
>      > >> Cc: idr@ietf.org; rtgwg-chairs@ietf.org; draft-templin-atn-bgp.all@ietf.org; idr-chairs@ietf.org; rtgwg@ietf.org
>      > >> Subject: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
>      > >>
>      > >> Reviewer: Stewart Bryant
>      > >> Review result: Has Issues
>      > >>
>      > >> This is basically a well written draft, although it has has a lots of spelling
>      > >> mistakes and needs to passed through a spell checker before a further version
>      > >> is uploaded.
>      > > Certainly we will fix that; apologies if it impacted the readability.
>      > >
>      > >> However, I have a number of issues that the chairs and authors should consider
>      > >> before deciding how to proceed.
>      > >>
>      > >> The first question to ask is whether the work belongs in RTGWG or in IDR since
>      > >> with the exception of the reference to  the optimization described in
>      > >> draft-templin-aerolink-82  this is a pure BGP solution. This is something that
>      > >> the RTGWG chairs should discuss with the IDR chairs. They should also discuss
>      > >> whether the draft needs to be looked at by a BGP specialist before RTGWG adopts
>      > >> it.
>      > > The document has been presented at RTGWG at three different IETF meetings
>      > > now and seems to have been well received there. So, we would like to see it
>      > > become an RTGWG working group item so we would not have to start the
>      > > socialization process over again, but your point is well taken. I do not have
>      > > enough experience with routing area working groups to understand all of
>      > > the implications, so any guidance would be appreciated.
>      >
>      > Actually it might also be a candidate for BESS (BGP enabled services).
>      >
>      > This is a chair/AD decision as much as anything, and they are normally
>      > guided by where
>      > the required expertise is.
>      
>      Jeff Tantsura posted a message on this subject that I will defer to.
>
> We actually did discuss with GROW and the chairs felt that this was an overlay network that may or may not be using the global Internet and, hence, not the purview of GROW.
>      
>      > >> The approach of building an overlay to separate the network from the main BGP
>      > >> system is a sound one, indeed from both the numbers and a security point of
>      > >> view, it would appear to be  essential in a safety critical application such as
>      > >> this. What bothers me is whether the author is underestimating the risk of
>      > >> running an application such as this over the public Internet. Whilst as they
>      > >> explain in the security section, high profile civil users do understand how to
>      > >> mitigate risk and minimize the effect of attack, none of these organizations
>      > >> are as large a target as civil aviation flight safety, and thus I would expect
>      > >> considerable resources, even to nation state level, to be directed at the
>      > >> attachment points. Hopefully ICAO fully understands the risks in running this
>      > >> on the public Internet as proposed. If ever there were an application for
>      > >> inter-domain network slicing, this is it.
>      > > For civil aviation, this is indeed a critical consideration. On the open public
>      > > Internet, for example, although IPsec could be used to establish secure
>      > > tunnels other threat vectors such as DDoS need to be considered. In my
>      > > understanding, ICAO is thinking about an underlay network comprising
>      > > secured physical links (e.g., fiber) and/or constructs like SD-WAN. But,
>      > > the construction of the underlay I think is something that has been
>      > > taken for granted and as you observe is pivotal to the design security.
>      > Indeed, I would have expected this to be on a secure network of some
>      > sort either purely
>      > private or some form of VPN. However, I am sure I read in your text that
>      > you were
>      > considering using the Public Internet much in the way of SD-WAN.
>      
>      This is an area that could certainly use more discussion, as we have been
>      seeing on the list. It occurs to me that, if critical services like online banking
>      can be made secure and robust while using the public Internet as an
>      underlay, then it may be that carrying air traffic management services via
>      secured tunnels over the Internet can also be possible. Failing that, it
>      seems like the only other option is to run dedicated private fibers with
>      no connections to the Internet - or are there other methods I may be
>      unaware of?
>
> We have described the BGP overlay in this draft and not the tunneling technology or how the security associations are disseminated. Perhaps, we should indicate this is out of scope and consider what attacks can be made on the ATN BGP control plane.
>      
>      > >> There is a suggestion in section 3 that for reasons of cost, globally unique
>      > >> ASNs would not be used. It is difficult to believe that cost is an issue in an
>      > >> SoF system. What is surely needed is the most robust approach, which in the
>      > >> long term is usually the cheapest anyway. Using global identifiers minimizes
>      > >> the possibility of error and issues if ever there is a routing leak, and thus
>      > >> the decision on whether to use private or global identifiers needs some careful
>      > >> thought beyond that expressed in this version of the draft.
>      > > I don't mind dropping the assertion that private AS numbers could be used.
>      > > As you say, there is probably no downside to procuring real global AS
>      > > numbers up front even if the overlay is never connected to the global
>      > > public Internet.
>      > >
>      > >> I am worried about the text towards the end of section three which proposes
>      > >> splitting the network into two or more disjoint systems, since that will surely
>      > >> lead to operation and integration issues.
>      > > Looking at that text with fresh eyes, I can see that a rewrite would help
>      > > bring across the point we are trying to make. What we want to have is
>      > > a means for supporting multiple independent RIBs and bounding the
>      > > numbers of prefixes each RIB will be sized to carry. So, if each RIB
>      > > supported up to 1M prefixes and we had 1K RIBs, we would be able
>      > > to service 1B prefixes or even a bit more. Does that help clarify? If so,
>      > > I will consult with co-authors to improve that text.
>      >
>      > Wow, are you sure that such a system is buildable?
>      
>      I have proven that a single set of core ASBRs can carry 1M BGP routes
>      even on lightweight linux virtual machines running Quagga. And, only
>      a few cASBRs (perhaps as many as 10) need to carry the full routing
>      table. The stub ASBRs only keep track of their associated Clients, and
>      configure a default route with a cASBR as the next hop for other prefixes.
>      So, this is a very leaned-down BGP service in comparison to the way BGP
>      works in the global public Internet.
>      
>      > What you seem to be building is a huge unaggregated routing system.
>      > People have considered that before and found that it was
>      > unimplimentatble. Remember that for every unaggregated prefix in the RIB
>      > you need an entry in the FIB. The FIB in a core router is high speed
>      > (expensive) memory and will be replicated on every line card.
>      
>      I have implemented it, and tested with up to 1M unaggregaed prefixes.
>      And, again, only a few nodes would need to maintain a full RIB/FIB.
>      
>      Remember also that the global public Internet has some 600K or more
>      unaggregated prefixes and seems to still be doing fine, so there is
>      precedence for a single RIB supporting such large numbers. So, if we
>      deploy 1K independent RIBs then our 1B target seems feasible.
>      
>      > I think that you really need to discuss your scaling requirements with
>      > some hardware
>      > vendors to verify that the design you propose can support the required
>      > aircraft
>      > population over the expected lifetime of the system.
>      >
>      > What I suspect that you need is some sort of formal hierarchy or
>      > layering in the system to support
>      > long term scaling, and that is going to be a lot easier if it is
>      > explicitly designed in on day one.
>      
>      I understand your concern, but I think we are OK. But, I will bring this
>      discussion point up with co-authors to make sure we are in agreement.
>
> I agree given the usage and scoping of MNPs.
>      
>      > >> In section 6 consideration is given to scaling the core, which looks basically
>      > >> under control for the existing flight profile, but with relatively little
>      > >> headroom for expansion.  Given the rise in UAVs, that will surely need to be
>      > >> integrated into a common flight safety system, I am concerned as to whether the
>      > >> authors have allowed sufficient room for expansion. Again hopefully the flight
>      > >> specialists have taken this into account and this is not a problem.
>      > > The upper bound in terms of scaling we were targeting was up to 1B
>      > > prefixes carried as BGP routes in order to allow for expansion. You are
>      > > right to observe that we are at the advent of wide-scale deployment of
>      > > UAVs, but this network would be only for those UAVs that fly to, from
>      > > or through airspace controlled by Air Traffic Controllers (ATCs) - meaning
>      > > it would only be for UAVs that take off and land at airports.
>      > Well, you are the application expert here, but that seems to be a
>      > critical assumption
>      > that you need to test in multiple geographies. Thinking about the London
>      > airports, that
>      > is quite a restriction.
>      
>      It is true that there are lots of airplanes out there, but probably not as many
>      as most people think. I think the numbers of airplanes deployed worldwide
>      is on the order of 10^4 - 10^5 - not millions upon millions. So, I think we
>      could live with a system that scales up to 1B unaggregated prefixes for
>      a long time.
>
> I  agree and the scale will be in the millions for the some time to come.
>
> Thanks,
> Acee
>
>      
>      > > For the future,
>      > > the types of UAVs that will eventually do that include unmanned cargo
>      > > delivery freighters and the like. But, we would only be expecting a few
>      > > thousands, ten-thousands, or hundred-thousansds of those; certainly
>      > > not millions and millions.
>      > I am always reminded that when IPv4 was designed, and (in much the same
>      > era Ethernet)
>      > their address sizes were an approximation to infinity. They are now a
>      > long way from infinity.
>      > This will be an expensive system to replace so it needs migration path
>      > to its infinity.
>      
>      It is a good point, but up to 1B unaggregaed prefixes already seems pretty
>      robust for state of the art dynamic routing protocols. So, to go to something
>      that supports even greater scaling would require either extending our BGP
>      based architecture (e.g., by adding another tier in the hierarchy) or introducing
>      a new architecture that scales in a similar fashion as the global DNS.
>      
>      > > For small UAVs that stay away from the airports, however, there is
>      > > potential for many millions of those or more. For them, the FAA and
>      > > NASA have a concept known as "Unmanned (air) Traffic Management"
>      > > or "UTM". The UTM would need to be a separate network unto itself,
>      > > but we believe these same BGP principles could apply there.
>      > >
>      >
>      > Best regards
>      >
>      > Stewart
>      >
>      
>      
>


From nobody Mon Aug  6 10:31:43 2018
Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C4A130E58; Mon,  6 Aug 2018 10:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 JbqJiEtsh1VL; Mon,  6 Aug 2018 10:31:38 -0700 (PDT)
Received: from mail-yb0-x242.google.com (mail-yb0-x242.google.com [IPv6:2607:f8b0:4002:c09::242]) (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 7D078130DDB; Mon,  6 Aug 2018 10:31:38 -0700 (PDT)
Received: by mail-yb0-x242.google.com with SMTP id l16-v6so5584747ybk.11; Mon, 06 Aug 2018 10:31:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=rJ9bgJoN5siylOE8zdKmMmBKlOgTodNvufSUclImWek=; b=IL2sAVPRIqjs8RoHTLH8hu3N6dKfs2N2ZgsTktotQnZEgCULHjcMsYCXAj/tT3ohfe cYHR++j296fstMzFpQDq4Dx7sprCX+LLBv4it7yuckzDBbPPQR2NAiX9YZfV/Wyf0jtJ zxoYQeIW656SVgCTfT2FHquTZ7PwT6RExXXakzB8wYTziTG24PZIB0vl95RU7aZTAK3j VsOTfXkInW4Dfo/01CenT2zasDNrERPwRGAMXkraMn1W+kYsJzyYWR8qlXcDIId81Hg+ kerAUf4Q/vL98tm2a7F3Ru0dlbbk3lbfXJafT5vy6fD3D3pTbjfzG9flTgv0eKLYmxp3 C2+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=rJ9bgJoN5siylOE8zdKmMmBKlOgTodNvufSUclImWek=; b=dLGHxecjIEonMeqFf/yUjjWYG0kMpZmKCqfGiuumAfm6rftSYwvKW4npYQhHSuJ+0t TZXbihoIgL/wItoCO2R5j1p+DmhM5V6OS/CtNPySxsmIE1aBbLeIu9aDQaw0ZbHGKF1N AhT47CaBFyQARcP5odJ0rRzH9Lhus7mzXVyY72b20DTPVtMezdquWQtVd6nabS1YfpuZ 82Vo4OfNF1V13R5zYZXft+2pFiy5OVM2+1MaZBXgYkqmXAiT5aa2SzE/GeRTY8OkwOZE lFe9DhEoL3ZlKEWWkPhTakjr7EnrhfJjLM4kaHJitOTYTLNla4OowZZN+FBaVRzRg7ww AeDQ==
X-Gm-Message-State: AOUpUlF+6+3RucOwk0vOJHBovkTPAWjRV+jc/BtD+AOL6SNm1BXXwVKy ftnxbr7l3KQ49TPUkQge5zE=
X-Google-Smtp-Source: AAOMgpcyWL3BZcnmAc1dfTvG03J4RV1kM5sLKqz2EdOZ1YwRrnN2RmOPEcPoei07KQ7RlbY5VYUFBA==
X-Received: by 2002:a25:ae87:: with SMTP id b7-v6mr4334160ybj.317.1533576697581;  Mon, 06 Aug 2018 10:31:37 -0700 (PDT)
Received: from [135.227.239.108] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id r3-v6sm8095393ywr.80.2018.08.06.10.31.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 10:31:36 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.f.0.180709
Date: Mon, 06 Aug 2018 10:31:35 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, "Templin (US), Fred L" <Fred.L.Templin@boeing.com>, Stewart Bryant <stewart.bryant@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "idr@ietf.org" <idr@ietf.org>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "draft-templin-atn-bgp.all@ietf.org" <draft-templin-atn-bgp.all@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Message-ID: <71E9CAC3-FF29-4A76-A6A2-477B39C61455@gmail.com>
Thread-Topic: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
References: <153243058668.22562.6511891462599952686@ietfa.amsl.com> <a6c05a6526184066bb0435131b8bfc54@XCH15-06-08.nw.nos.boeing.com> <7864a95d-754a-2bb9-d1b6-810202eeb0a7@gmail.com> <3a7ff55381db4adfa1b666356387a843@XCH15-06-08.nw.nos.boeing.com> <CE4A8029-1BDD-4DC3-8A87-2E51DD266D55@cisco.com>
In-Reply-To: <CE4A8029-1BDD-4DC3-8A87-2E51DD266D55@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hUK3IjBEdXrHFFBuEPNro3MNiks>
Subject: Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 17:31:41 -0000

Acee - thanks for your comments.

Authors - after you have published the updated draft that addresses rtgdir =
early review and includes all the clarifications posted , the chairs would l=
ike to start wg adoption call.
We are really happy to see good discussion on the list and timely answers!

Please do proceed.=20

Cheers,
Jeff & Chris

=EF=BB=BFOn 8/6/18, 08:17, "Acee Lindem (acee)" <acee@cisco.com> wrote:

    Hi Stewart, Fred,=20
   =20
    See further responses below.
   =20
    =EF=BB=BFOn 7/25/18, 6:22 PM, "Templin (US), Fred L" <Fred.L.Templin@boeing.c=
om> wrote:
   =20
        Hello Stewart,
       =20
        See below for further follow-up:
       =20
        Thanks - Fred
       =20
        > -----Original Message-----
        > From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
        > Sent: Wednesday, July 25, 2018 2:14 AM
        > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; rtg-dir@iet=
f.org
        > Cc: idr@ietf.org; rtgwg-chairs@ietf.org; draft-templin-atn-bgp.al=
l@ietf.org; idr-chairs@ietf.org; rtgwg@ietf.org
        > Subject: Re: [Idr] Rtgdir early review of draft-templin-atn-bgp-0=
7
        >=20
        >=20
        >=20
        > On 24/07/2018 20:53, Templin (US), Fred L wrote:
        > > Hello Stewart,
        > >
        > > Thank you for your effort in reviewing the document. Please see=
 below for
        > > follow-up discussion:
        > >
        > > Fred
        > >
        > >> -----Original Message-----
        > >> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Stewart B=
ryant
        > >> Sent: Tuesday, July 24, 2018 4:10 AM
        > >> To: rtg-dir@ietf.org
        > >> Cc: idr@ietf.org; rtgwg-chairs@ietf.org; draft-templin-atn-bgp=
.all@ietf.org; idr-chairs@ietf.org; rtgwg@ietf.org
        > >> Subject: [Idr] Rtgdir early review of draft-templin-atn-bgp-07
        > >>
        > >> Reviewer: Stewart Bryant
        > >> Review result: Has Issues
        > >>
        > >> This is basically a well written draft, although it has has a =
lots of spelling
        > >> mistakes and needs to passed through a spell checker before a =
further version
        > >> is uploaded.
        > > Certainly we will fix that; apologies if it impacted the readab=
ility.
        > >
        > >> However, I have a number of issues that the chairs and authors=
 should consider
        > >> before deciding how to proceed.
        > >>
        > >> The first question to ask is whether the work belongs in RTGWG=
 or in IDR since
        > >> with the exception of the reference to  the optimization descr=
ibed in
        > >> draft-templin-aerolink-82  this is a pure BGP solution. This i=
s something that
        > >> the RTGWG chairs should discuss with the IDR chairs. They shou=
ld also discuss
        > >> whether the draft needs to be looked at by a BGP specialist be=
fore RTGWG adopts
        > >> it.
        > > The document has been presented at RTGWG at three different IET=
F meetings
        > > now and seems to have been well received there. So, we would li=
ke to see it
        > > become an RTGWG working group item so we would not have to star=
t the
        > > socialization process over again, but your point is well taken.=
 I do not have
        > > enough experience with routing area working groups to understan=
d all of
        > > the implications, so any guidance would be appreciated.
        >=20
        > Actually it might also be a candidate for BESS (BGP enabled servi=
ces).
        >=20
        > This is a chair/AD decision as much as anything, and they are nor=
mally
        > guided by where
        > the required expertise is.
       =20
        Jeff Tantsura posted a message on this subject that I will defer to=
.
   =20
    We actually did discuss with GROW and the chairs felt that this was an =
overlay network that may or may not be using the global Internet and, hence,=
 not the purview of GROW.=20
       =20
        > >> The approach of building an overlay to separate the network fr=
om the main BGP
        > >> system is a sound one, indeed from both the numbers and a secu=
rity point of
        > >> view, it would appear to be  essential in a safety critical ap=
plication such as
        > >> this. What bothers me is whether the author is underestimating=
 the risk of
        > >> running an application such as this over the public Internet. =
Whilst as they
        > >> explain in the security section, high profile civil users do u=
nderstand how to
        > >> mitigate risk and minimize the effect of attack, none of these=
 organizations
        > >> are as large a target as civil aviation flight safety, and thu=
s I would expect
        > >> considerable resources, even to nation state level, to be dire=
cted at the
        > >> attachment points. Hopefully ICAO fully understands the risks =
in running this
        > >> on the public Internet as proposed. If ever there were an appl=
ication for
        > >> inter-domain network slicing, this is it.
        > > For civil aviation, this is indeed a critical consideration. On=
 the open public
        > > Internet, for example, although IPsec could be used to establis=
h secure
        > > tunnels other threat vectors such as DDoS need to be considered=
. In my
        > > understanding, ICAO is thinking about an underlay network compr=
ising
        > > secured physical links (e.g., fiber) and/or constructs like SD-=
WAN. But,
        > > the construction of the underlay I think is something that has =
been
        > > taken for granted and as you observe is pivotal to the design s=
ecurity.
        > Indeed, I would have expected this to be on a secure network of s=
ome
        > sort either purely
        > private or some form of VPN. However, I am sure I read in your te=
xt that
        > you were
        > considering using the Public Internet much in the way of SD-WAN.
       =20
        This is an area that could certainly use more discussion, as we hav=
e been
        seeing on the list. It occurs to me that, if critical services like=
 online banking
        can be made secure and robust while using the public Internet as an
        underlay, then it may be that carrying air traffic management servi=
ces via
        secured tunnels over the Internet can also be possible. Failing tha=
t, it
        seems like the only other option is to run dedicated private fibers=
 with
        no connections to the Internet - or are there other methods I may b=
e
        unaware of?
   =20
    We have described the BGP overlay in this draft and not the tunneling t=
echnology or how the security associations are disseminated. Perhaps, we sho=
uld indicate this is out of scope and consider what attacks can be made on t=
he ATN BGP control plane.=20
       =20
        > >> There is a suggestion in section 3 that for reasons of cost, g=
lobally unique
        > >> ASNs would not be used. It is difficult to believe that cost i=
s an issue in an
        > >> SoF system. What is surely needed is the most robust approach,=
 which in the
        > >> long term is usually the cheapest anyway. Using global identif=
iers minimizes
        > >> the possibility of error and issues if ever there is a routing=
 leak, and thus
        > >> the decision on whether to use private or global identifiers n=
eeds some careful
        > >> thought beyond that expressed in this version of the draft.
        > > I don't mind dropping the assertion that private AS numbers cou=
ld be used.
        > > As you say, there is probably no downside to procuring real glo=
bal AS
        > > numbers up front even if the overlay is never connected to the =
global
        > > public Internet.
        > >
        > >> I am worried about the text towards the end of section three w=
hich proposes
        > >> splitting the network into two or more disjoint systems, since=
 that will surely
        > >> lead to operation and integration issues.
        > > Looking at that text with fresh eyes, I can see that a rewrite =
would help
        > > bring across the point we are trying to make. What we want to h=
ave is
        > > a means for supporting multiple independent RIBs and bounding t=
he
        > > numbers of prefixes each RIB will be sized to carry. So, if eac=
h RIB
        > > supported up to 1M prefixes and we had 1K RIBs, we would be abl=
e
        > > to service 1B prefixes or even a bit more. Does that help clari=
fy? If so,
        > > I will consult with co-authors to improve that text.
        >=20
        > Wow, are you sure that such a system is buildable?
       =20
        I have proven that a single set of core ASBRs can carry 1M BGP rout=
es
        even on lightweight linux virtual machines running Quagga. And, onl=
y
        a few cASBRs (perhaps as many as 10) need to carry the full routing
        table. The stub ASBRs only keep track of their associated Clients, =
and
        configure a default route with a cASBR as the next hop for other pr=
efixes.
        So, this is a very leaned-down BGP service in comparison to the way=
 BGP
        works in the global public Internet.
       =20
        > What you seem to be building is a huge unaggregated routing syste=
m.
        > People have considered that before and found that it was
        > unimplimentatble. Remember that for every unaggregated prefix in =
the RIB
        > you need an entry in the FIB. The FIB in a core router is high sp=
eed
        > (expensive) memory and will be replicated on every line card.
       =20
        I have implemented it, and tested with up to 1M unaggregaed prefixe=
s.
        And, again, only a few nodes would need to maintain a full RIB/FIB.
       =20
        Remember also that the global public Internet has some 600K or more
        unaggregated prefixes and seems to still be doing fine, so there is
        precedence for a single RIB supporting such large numbers. So, if w=
e
        deploy 1K independent RIBs then our 1B target seems feasible.
       =20
        > I think that you really need to discuss your scaling requirements=
 with
        > some hardware
        > vendors to verify that the design you propose can support the req=
uired
        > aircraft
        > population over the expected lifetime of the system.
        >=20
        > What I suspect that you need is some sort of formal hierarchy or
        > layering in the system to support
        > long term scaling, and that is going to be a lot easier if it is
        > explicitly designed in on day one.
       =20
        I understand your concern, but I think we are OK. But, I will bring=
 this
        discussion point up with co-authors to make sure we are in agreemen=
t.
   =20
    I agree given the usage and scoping of MNPs.=20
       =20
        > >> In section 6 consideration is given to scaling the core, which=
 looks basically
        > >> under control for the existing flight profile, but with relati=
vely little
        > >> headroom for expansion.  Given the rise in UAVs, that will sur=
ely need to be
        > >> integrated into a common flight safety system, I am concerned =
as to whether the
        > >> authors have allowed sufficient room for expansion. Again hope=
fully the flight
        > >> specialists have taken this into account and this is not a pro=
blem.
        > > The upper bound in terms of scaling we were targeting was up to=
 1B
        > > prefixes carried as BGP routes in order to allow for expansion.=
 You are
        > > right to observe that we are at the advent of wide-scale deploy=
ment of
        > > UAVs, but this network would be only for those UAVs that fly to=
, from
        > > or through airspace controlled by Air Traffic Controllers (ATCs=
) - meaning
        > > it would only be for UAVs that take off and land at airports.
        > Well, you are the application expert here, but that seems to be a
        > critical assumption
        > that you need to test in multiple geographies. Thinking about the=
 London
        > airports, that
        > is quite a restriction.
       =20
        It is true that there are lots of airplanes out there, but probably=
 not as many
        as most people think. I think the numbers of airplanes deployed wor=
ldwide
        is on the order of 10^4 - 10^5 - not millions upon millions. So, I =
think we
        could live with a system that scales up to 1B unaggregated prefixes=
 for
        a long time.=20
   =20
    I  agree and the scale will be in the millions for the some time to com=
e.=20
   =20
    Thanks,
    Acee
   =20
       =20
        > > For the future,
        > > the types of UAVs that will eventually do that include unmanned=
 cargo
        > > delivery freighters and the like. But, we would only be expecti=
ng a few
        > > thousands, ten-thousands, or hundred-thousansds of those; certa=
inly
        > > not millions and millions.
        > I am always reminded that when IPv4 was designed, and (in much th=
e same
        > era Ethernet)
        > their address sizes were an approximation to infinity. They are n=
ow a
        > long way from infinity.
        > This will be an expensive system to replace so it needs migration=
 path
        > to its infinity.
       =20
        It is a good point, but up to 1B unaggregaed prefixes already seems=
 pretty
        robust for state of the art dynamic routing protocols. So, to go to=
 something
        that supports even greater scaling would require either extending o=
ur BGP
        based architecture (e.g., by adding another tier in the hierarchy) =
or introducing
        a new architecture that scales in a similar fashion as the global D=
NS.=20
       =20
        > > For small UAVs that stay away from the airports, however, there=
 is
        > > potential for many millions of those or more. For them, the FAA=
 and
        > > NASA have a concept known as "Unmanned (air) Traffic Management=
"
        > > or "UTM". The UTM would need to be a separate network unto itse=
lf,
        > > but we believe these same BGP principles could apply there.
        > >
        >=20
        > Best regards
        >=20
        > Stewart
        >=20
       =20
       =20
   =20
   =20



From nobody Mon Aug 13 08:01:59 2018
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E418129C6B; Mon,  6 Aug 2018 14:54:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: idr@ietf.org, The IESG <iesg@ietf.org>, Susan Hares <shares@ndzh.com>, idr-chairs@ietf.org, draft-ietf-idr-bgp-prefix-sid@ietf.org, John Scudder <jgs@juniper.net>, jgs@juniper.net, aretana.ietf@gmail.com, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <153359247811.26607.814277776139509955.idtracker@ietfa.amsl.com>
Date: Mon, 06 Aug 2018 14:54:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/z9YPqf8eaMf06FGO6bJqDanV1Kw>
X-Mailman-Approved-At: Mon, 13 Aug 2018 08:01:58 -0700
Subject: [Idr] Protocol Action: 'Segment Routing Prefix SID extensions for BGP' to Proposed Standard (draft-ietf-idr-bgp-prefix-sid-27.txt)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 21:54:38 -0000

The IESG has approved the following document:
- 'Segment Routing Prefix SID extensions for BGP'
  (draft-ietf-idr-bgp-prefix-sid-27.txt) as Proposed Standard

This document is the product of the Inter-Domain Routing Working Group.

The IESG contact persons are Alvaro Retana, Martin Vigoureux and Deborah
Brungard.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/





Technical Summary

   This document defines an optional, transitive BGP attribute for
   announcing BGP Prefix Segment Identifiers (BGP Prefix-SID)
   information.

Working Group Summary

   WG consensus is strong.

   This document already went through IESG Evaluation.  After 
   approval, the WG decided to remove the IPv6 SID TLV for lack 
   of implementation, and because there are better proposals on 
   the table.  IOW, IPv6 is not being ignored -- it is just being moved 
   to another document.  The document went back to the WG for 
   discussion, an updated WGLC, and then again through IETF LC.

Document Quality

  Existing Implementations of protocol: 2 companies,  4 implementations see: 
   https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-prefix-sid%20implementations

Personnel

 Document Shepherd: Susan Hares 
 AD:  Alvaro Retana 


From nobody Mon Aug 13 12:27:16 2018
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0670B130FB5; Mon, 13 Aug 2018 12:27:08 -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, HTML_MESSAGE=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 WYwGoqm4eWOr; Mon, 13 Aug 2018 12:27:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 718D0130E31; Mon, 13 Aug 2018 12:27:06 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 24746B2A2FB5D; Mon, 13 Aug 2018 20:27:01 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 13 Aug 2018 20:27:02 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.34]) with mapi id 14.03.0399.000; Mon, 13 Aug 2018 12:26:57 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "Jeff Tantsura" <jefftant.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
Thread-Topic: Preventing BGP Route leak (Hijack) for Management Channel BGP session
Thread-Index: AdQzO4r0PzSwhpZvSCmMNMmO/EiBoA==
Date: Mon, 13 Aug 2018 19:26:56 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.118]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0DAE87sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iuvFnHjS1JK0FjK6r70Bvzfe7mM>
Subject: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 19:27:08 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DAE87sjceml521mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


One of the comments to https://datatracker.ietf.org/doc/draft-dm-net2cloud-=
gap-analysis/ the In RTGwg session of IETF102 is that using BGP session to =
pass configuration keys for IPsec can be risky even if the path between RR =
& node is secure (say via TLS) due to BGP route leak (Hijack).

But the BGP session to carry IPsec configurations is via BGP management ses=
sion, which is completely isolated form the dataplane BGP sessions.

Does it still post a risk?

Linda Dunbar


--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DAE87sjceml521mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri",sans-serif;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">One of the comments to <a href=3D"https://datatracke=
r.ietf.org/doc/draft-dm-net2cloud-gap-analysis/">
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/</a> the I=
n RTGwg session of IETF102 is that using BGP session to pass configuration =
keys for IPsec can be risky even if the path between RR &amp; node is secur=
e (say via TLS) due to BGP route leak
 (Hijack). <o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">But the BGP session to carry IPsec configurations is=
 via BGP management session, which is completely isolated form the dataplan=
e BGP sessions.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Does it still post a risk? &nbsp;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Linda Dunbar<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DAE87sjceml521mbxchi_--


From nobody Mon Aug 13 14:47:40 2018
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F79126F72; Mon, 13 Aug 2018 14:47:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: idr@ietf.org
Message-ID: <153419685890.25144.2679821016361698468@ietfa.amsl.com>
Date: Mon, 13 Aug 2018 14:47:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8dZU7GHfHinRZ878WfmmxKu-aJE>
Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2018 21:47:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State
        Authors         : Jeff Tantsura
                          Uma Chunduri
                          Greg Mirsky
                          Siva Sivabalan
	Filename        : draft-ietf-idr-bgp-ls-segment-routing-msd-02.txt
	Pages           : 7
	Date            : 2018-08-13

Abstract:
   This document defines a way for a Border Gateway Protocol Link-State
   (BGP-LS) speaker to advertise multiple types of supported Maximum SID
   Depths (MSDs) at node and/or link granularity.

   Such advertisements allow logically centralized entities (e.g.,
   centralized controllers) to determine whether a particular SID stack
   can be supported in a given network.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-02
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Aug 16 12:59:37 2018
Return-Path: <erosen@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30221130F26; Thu, 16 Aug 2018 12:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.721
X-Spam-Level: 
X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 Yei9t2Bzj3TQ; Thu, 16 Aug 2018 12:59:32 -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 151FB130E22; Thu, 16 Aug 2018 12:59:32 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7GJxRfN006905; Thu, 16 Aug 2018 12:59:28 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : subject : to : references : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=BqyLHc9z2w9mwF/zt3jGzboyMgzK375S1qsUlGly6/c=; b=QwRkLzBBhitkuYiIhUPh1SbbcZSXUvvd26Zk9BJT0VG1JxtQOXpSm+yckWolDeuFEia7 vC1HpkoHxRRjEkidLgN7nrHAp2U3YnBwXY60irTG1aKtMlXK+Jm6yDx/cOdm9IbCyBRi mRbTe/QeLgfwlW9Z/WwOrp0hkHsi/hgVU8Df8pKrgN7W3xlk14KGBTILyamSLLeo2Ecq T/CQ+JgXngDb9eUpTI98WI2XOpMf5Y+m9UoIyE+ypZaKImtfddb/UZuMJi8UIc5EAQSL /HOeUaMG4C9swH1adl5y1yU7mKqxbkuE48cSkgZwoKoW4uHpBcoM7A0BDG8bVbdi5jI7 NA== 
Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0083.outbound.protection.outlook.com [216.32.180.83]) by mx0a-00273201.pphosted.com with ESMTP id 2kw7qp8vnc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Aug 2018 12:59:27 -0700
Received: from [172.29.34.132] (66.129.241.12) by DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.13; Thu, 16 Aug 2018 19:59:20 +0000
From: Eric C Rosen <erosen@juniper.net>
To: Linda Dunbar <linda.dunbar@huawei.com>, "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com>
Message-ID: <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net>
Date: Thu, 16 Aug 2018 15:59:16 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------89DFA5C19FD77CE743BE42B6"
Content-Language: en-US
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: MWHPR19CA0018.namprd19.prod.outlook.com (2603:10b6:300:d4::28) To DM5PR0501MB3864.namprd05.prod.outlook.com (2603:10b6:4:7b::27)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 353c6e30-960d-4197-a8fa-08d603b2c239
X-MS-Office365-Filtering-HT: Tenant
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM5PR0501MB3864; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR0501MB3864; 3:37i7Of5UR2Yg0kOtSoin6rFlMtg8GifW6uSj9gmFHzPaAHrNjEKvGwK5/+xsA87aS32C7uqEU7RPBPLzYn7TPxIVbSsnNRE9FUQMrB2AwqHR0SVygzx3VdeOYc/5GNDm1xEaoOHWq+Dmi4Zo8TjTB4y7TX9BgWoqjb2ZWz5CUwrcZCfgl6C0cbVHi6fXeHV7br2uP4FBa27PrkaB+afGdFdeWhJdNfJh6wV0SB2YDTeO09IfkPLIyu76UdMGFqX8; 25:M2+tXZwRKsVAgBfOiOPLn+HZSSeSD9RsC7bvWfeKPeWuTb4zfL3qu1sVGP+5sNxQYZwC7JsEtPIAwwZGsIZN0ZcpazZ4vqkQjOR7Y/5NM6rTodpDycgmZW03XQjtyUNsXa0M02i+8cP40dkLeviOp3SB1iEhuC/CUhVrOSSjqSH0m1+VV5YypfEi/RnV+u3E+tu7OhnTq02JUwZY1CyLFHMNFkgJONc8yMd4oBv04E64C4z8Fd7jXNC/bVJoE5pmO9WRZSd4EnE1gN3UWKDJs746aYNnS72dUFDs61697VmiTUBfyZ2MR01+LcQBS09PmLB+TILoVR61k7Erv3wB8w==; 31:eIGhCTxHFXyWAChVUalBo501TF4UlACq6eTM2Mk9CPFfcCxf/Q7INWjJQHricGvvJsZdMO8KUtSvoOMp1bBnGTRy9g07Ltzn8ZTT0k3vZeyyOBEXAogTj4VizCKCv1tnGoMxg/NaU0ijcOplDcVzERORsLfNEcDTa2e5yGTX6/F8oITZcyKxmLr7WBAmR/sL7poR4AUuRW7OwMNjIuqZN0mp4MnrqfPbbjhZMV1llng=
X-MS-TrafficTypeDiagnostic: DM5PR0501MB3864:
X-Microsoft-Exchange-Diagnostics: 1; DM5PR0501MB3864; 20:3TfoFsq3P+yZL/+m2Mg24BctEMit2/DwjixSM+wPbn4Br/90caC+8WrTrIHxmNJoF3KbRXj/SSnhfUZDpdwp1u0hPwvhX3FZRpsyxL45kjjubMRoHgJDcmv8zInBZpF7F6oAvoGroQW0a2qpDy9HeJW6P33jeXwjMem8rBpc7uuCxsZyEn1wL6HamnTTIC5jcDVqXA1tWJMVYzqLzE2Haei2OreBDDBxayq8y4ogRLMyPbTO8Q3TiFGB9P0yTjDqFgPwZPFimiPhDFWtR/Vp8Wm3btMjsvDgBJIqJx396tYAKWZMNY7wbSb/WiPmEtpJl9XtJCnTgZB4QT9ou8J2jDJaD80YDBn62HtX2ajFe/d+JNDX2Hs1pYW73Vqute/RM+0NzXPMOv73QUotTSytCS9gAUi/Mt+BSD7SFlkAJPfwPBtbY7sx62uzLAimEzVgP81ZvaLrsU/5KIDVKOMqwb3HSfagnj+PHlQe8XAiUnJkpYZjIs9V4ZWRdELqzWBhmVRreAaTWTVnTwIu0iskmMqXQ7qqsPb2slfw37oge47/kQcvlsATSY56mHcQztUVifyWeIe8iVl1USdU/9NHKNBk7duTpFiAYrtdTftVWQg=
X-Microsoft-Antispam-PRVS: <DM5PR0501MB38640781A39FC239950FCC1AD43E0@DM5PR0501MB3864.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(72170088055959)(120809045254105)(50582790962513); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:DM5PR0501MB3864; BCL:0; PCL:0; RULEID:; SRVR:DM5PR0501MB3864; 
X-Microsoft-Exchange-Diagnostics: 1; DM5PR0501MB3864; 4:BuA6KK6YmNJ0gEcyXPzpcSO5BjKE/AzVhctfsI+14aP/aHxLl7t4H/AAwwHTQrYIGDT2MAOdrBhBH5mmWt1l9dBn0Lc9hdTdEYfzEL3jZuLHak5UJMKMCi3g5h1uhb+5PQb+NNDWVfQX56dxxtWg4W9VOrD15yr3s6abMEHV627fObXu98aTMzr+GY1M0rr1lZUOKnwxfwhUbthFPQD2Kj63l0EFjXQM8SSsX65DUt5Ml3sSPJgxczSkW2F1asHNtPY+WJIhcH++YmDLgXbYrZ79vFQfUGe/WdpiHh8Q9DUxHbvc+Lv+7WQgL7GMzWG+kkMq/miWjdQgHIirFTim8WcrLq/q0XXv0ZQqcPy2cN7K5FeAcIsa4nh2toU0VR6x0NfgfPk9hstGxy+7m7IlslrF9rP0GLdRNSaVWhZGmYY=
X-Forefront-PRVS: 07665BE9D1
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(346002)(376002)(136003)(39860400002)(366004)(396003)(189003)(199004)(106356001)(26005)(476003)(16526019)(2906002)(64126003)(5660300001)(65826007)(53546011)(3260700006)(25786009)(97736004)(77096007)(53936002)(6486002)(478600001)(966005)(2616005)(5024004)(956004)(486006)(68736007)(11346002)(81156014)(31696002)(37036004)(6116002)(7736002)(3846002)(2501003)(110136005)(606006)(6306002)(58126008)(65806001)(8676002)(446003)(65956001)(236005)(6666003)(66066001)(52116002)(84326002)(54896002)(76176011)(36756003)(39060400002)(386003)(105586002)(16586007)(8936002)(81166006)(6246003)(31686004)(86362001)(316002)(16576012)(2201001)(575784001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR0501MB3864; H:[172.29.34.132]; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR0501MB3864; 23:mFpGZ0MktLLfOiIB7s7uCpoezfKeJiD3umqZUZT?= =?us-ascii?Q?qfXODhCJPvdAukUV/Z3PSE1Vv3ZqC93l/Ql70IY+g6ZvMF9P4byZ2v2Rruvy?= =?us-ascii?Q?ZrRAcST/6fWbJmrwo8IUa3lcjE7bnqKCvbxffbNF6Obt9kIPjT+kZwQx5AHV?= =?us-ascii?Q?4VHGkpMGTy3GLY1QPC9h1VUJSi9ScdfmTxGoA3coa8gbQSxmqcyuk7yKYoHN?= =?us-ascii?Q?BwMgXtDQ5aBo5yvYjAjxhCeorRqR0wtYSEa83S5eudfqVeMA5JIvRAq7L7rg?= =?us-ascii?Q?FTLGEoR4PeGmTkkf12AeIQENdbEmxKVKdhoYXB92NJTMBx7PDtJaUmJsklUW?= =?us-ascii?Q?ndjKzdG1ZVrluyCyRHwWGaom4rMw6vH2P7XaS7Z0V4tSQv4qqBf/GFUCZCLQ?= =?us-ascii?Q?U2CfIRvps88MqFbPtZxiMByBeOBiQi/aC6gp5/vWVN/0vg14wq4+4ZfKrhzA?= =?us-ascii?Q?nWtxrmbf1se7YnSX+oZoneZWI59XKeeBMb+1kuxiVf9Fx+bAKaheF1NKoHNo?= =?us-ascii?Q?L/f7JsG+pyp2CmToiduvBBpt4mgr8UlbCB5Z99aFT7iu4lmHmDylVjqvcc48?= =?us-ascii?Q?Uu2ka1wAgW5Yohv4A/o0EBB+EIYm0kOcOcnLVwVkUmYLog6Gf0dXvfEZ8XtZ?= =?us-ascii?Q?Ol9zkl2dQgazotAWE7DiQUDGxtoRTf1a+EN7AIINOs/By6KWbVI/9JWIlvTm?= =?us-ascii?Q?+qvz1zNuNHzZ1CLbmpUAHIxY42cujYrMQPa/KKO5Hrhh4U4FUejc5IxHLQPB?= =?us-ascii?Q?xETtRE8VlJB0kc2e4tFbXLdV5Fo0ElWwBrz8EyW4UaXQ1coaJun1XCcQk9Kj?= =?us-ascii?Q?uD84S5uS3xftXf58c2AoW39ix45jJJ0r3gEXy04V+n8qS7yAEHaxw3emDQHl?= =?us-ascii?Q?mH7Mehl387WZhfuEhGvmWKgx3As7pxX2H1yP/8IlqShTuDlK1btXCqR9EkVV?= =?us-ascii?Q?AcIAHtQaFTDg4TaT0c+Z6fMwGz6U8wPSD3uPWOnXDXqtH8I0JD2FyMSzJne2?= =?us-ascii?Q?V5e9PCkQWdp4bdadW3CBSvZYhXGenfgakxqgkbCeqKVk7mWjIdKwLqej844y?= =?us-ascii?Q?yk2qCKJBverUsZX6VDUnQcFq8CQb94ZPXvT7Wgiqm92b2y5oHq2KnR9kp36q?= =?us-ascii?Q?wBYUN20t6NIugVaKgG/bjxndi1dANOyLGhbYfnsfJc0W1/87qNcRCmG0wKsZ?= =?us-ascii?Q?LmMKJ1V5k90DoHXa7ntgc7rnPScBcJHF8nv2ta//GoU7bvFOJSMJKpJk4TGG?= =?us-ascii?Q?ekVQYnwUwBkB6vkLhodZAQcResG9s7y5SBjk0q+OMqJmpO7FWKJffJMuPgod?= =?us-ascii?Q?S8YqQ2F+v91nWcwWG9Nsrx6DDuLcJ2FqnH711OM+DO5Nptomgc7JaBuNtoRz?= =?us-ascii?Q?sypZcEM4ewRRXK337W+SqJeGn+KVFDdptTecsjrnDrptIt/FEo8iasiARkQY?= =?us-ascii?Q?UUxJwFMHMHmGnNAWgt9RIhXtoujr3vVNBcyGGJVOlzSFD0xQ+4cY4RaMEQsV?= =?us-ascii?Q?0DbnWXQxCSGGE6JsLpMjTikQh+hS0ppYucXs=3D?=
X-Microsoft-Antispam-Message-Info: aamMBBgfhAXrYJsg/ehuQqD6ErGLuAVT+46XhWjwJKS+wdSFvUDHPBKgMmMsId/p3TjiD3em1bopcKriYQwHGba1rhNSnAusb7pLsQMFUF3cYBPExjYDy6MuuwtXsqItEzvGeuynPI5B8di/79vTuOBiniTV7kI1/6+WqQ7PGbOJi5rgexn0QBZpd0F/fRaL5QF5MgjTsktj0HSzaKkE3u3aLPEtX0PX7hi54yd0MmtS9ddSivM+OyM/0PZrUJVvPcXC/B7uCSMYNEUEfQr4mAVyKq8U7dMboGoxt7JIuJtpeqzWZDo/twi+p/WtbwRHj7TvrhEfX0o9Vc6dgy17l4b6ijnVAGSTamt7wb3Hjyc=
X-Microsoft-Exchange-Diagnostics: 1; DM5PR0501MB3864; 6:fCsHi3U0fyaU79ng7sHsQvzSaMBJPuuxMrP5fh3gYP/6ZEZTysfoAXN/7ltnD3nfgwCfhJLvl6lZBgWAF6Txmw0cpal4xs86wyrovz1NmI07dp3/gzGdiCSwRczDhcivEw/FURrWF7osEB3GmKPo+pW+jURZb2EugL9nOCqXVC/r7DxY2Hn5cB06ZcvnYNABx3jzElSf0h5lN5Gq8wtobSXzjBAQ7CMlX5qqVEMqlNTnOS7JAsh0lrFYPQnt4xK1+/fZ33ODC2SVsVocLkJx+HBUmKCicX+Q4H55R4smf+qZZuXH8RKQ9Oukrfd6a/CsOM5R991ni5XR1HbWvGszEitO2ecJt9JC6anFLyD2QNe1jJ5NSZ1Hu/lRfeCPQdfGctOg7Wv2w1DbPp1b9xD/BCZ5TI/0HBzn/nfOs1sa7gGmIiZFDZkU2TQPCbe0xYMYrMJKcSbvtF7Su6ldHIkYlQ==; 5:+p8aK0TfY1X4nK3Ow4vzRE45RyfVXjVrcg5S3lsgQiqmXbJsWH0CJ/Z2PE+VMFo/ZXpNlRWZhSxfQo2PNz2Gk8YDQ0H4CA/KJREXXhRhswy/cQLFo7iEO+l176XEi6TKKxBAOL626ddjLAMFzovtAMCcpC0ZZUFakHIrHPQDUao=; 7:BiGFC4/WBybCe+zuj6e5sk8nOlcOFmpGVyhLZJAtJ8Da+IsltIiM/xxYpmsVPt/l+grWWYNFP2zUNQnc4dwl8BNKQXoHYw07xofYOVAiKblh7mCF8EpkqAMeCq3w7+6VBj0OlhPSkyu/yp1YQM7j/VetW7sLjlcsoH1yotF7NyGnftakqwJ8DfS2E/kahN9DKxdhcbO2eqXrfTI1P+RYvYhPYxMTujaEOsocpTagIcR0iQWW2W/9+iML8gxNN06t
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2018 19:59:20.1463 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 353c6e30-960d-4197-a8fa-08d603b2c239
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3864
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-16_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808160204
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/W_BNCvo-LdgbLdHJeBPcNQoN15c>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 19:59:35 -0000

This is a multi-part message in MIME format.
--------------89DFA5C19FD77CE743BE42B6
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

On 8/13/2018 3:26 PM, Linda Dunbar wrote:
>
> One of the comments to 
> https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/ 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=RToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=> 
> the In RTGwg session of IETF102 is that using BGP session to pass 
> configuration keys for IPsec can be risky even if the path between RR 
> & node is secure (say via TLS) due to BGP route leak (Hijack).
>
> But the BGP session to carry IPsec configurations is via BGP 
> management session, which is completely isolated form the dataplane 
> BGP sessions.
>

I'm not sure I have the whole context, but the question seems to be 
whether it could ever be safe to use BGP to distribute secret keys.

Presumably:

- The keys would be carried in an attribute that can only be attached by 
UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only 
used to carry management/configuration information.

- UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are 
adequately secured so as to provide privacy, integrity and authentication.

- The UPDATEs would carry the NO_ADVERTISE community (to make sure they 
are not propagated further).

- None of the BGP systems involved would allow any sort of "BGP 
monitoring" that might expose the unencrypted contents of the UPDATEs.

In this scenario, I don't think it matters whether the secure BGP 
session also carries other AFI/SAFIs.

The privacy properties of this scenario are pretty good, in theory, but 
I don't think they are really good enough for distributing secret keys.

- Once you're using BGP to distribute information, it is inevitable that 
someone will decide to remove the "NO_ADVERTISE" and allow the 
information to be propagated through intermediate nodes (RRs or ASBRs) 
to the actual target node.  After all, one of the main values of using 
BGP to distribute stuff is that you get a big distribution system.  Even 
if all the intermediate nodes are trusted and all the intermediate BGP 
sessions have adequate privacy/integrity/authentication, you still 
wouldn't want to expose the secret keys to those nodes.  You might trust 
those nodes to see all the routing information, and even to see most of 
the management information, but you probably don't want them to see all 
the secret keys.  And you probably don't want the secret keys stored in 
the clear on those intermediate nodes.

- I would worry about BGP monitoring procedures creating a backdoor 
through which the secret keys would be exposed.

- No matter how careful you are, when you use BGP you can be pretty sure 
that your UPDATEs will end up somewhere they're not supposed to go.  
It's just too easy to make mistakes.
So I don't think I'd try to do dynamic keying by attaching the actual 
keys to BGP UPDATEs.  At most I'd use BGP to distribute parameters that 
could then be used by something like IKEv2 to actually fetch the secret 
keys.


--------------89DFA5C19FD77CE743BE42B6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 8/13/2018 3:26 PM, Linda Dunbar wrote:<br>
    <blockquote type="cite"
cite="mid:4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com">
      <p class="MsoNormal">One of the comments to <a
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&amp;d=DwMFAg&amp;c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&amp;r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&amp;m=RToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&amp;s=9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&amp;e="
          moz-do-not-send="true">
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/</a>
        the In RTGwg session of IETF102 is that using BGP session to
        pass configuration keys for IPsec can be risky even if the path
        between RR &amp; node is secure (say via TLS) due to BGP route
        leak (Hijack). <o:p></o:p></p>
      <p class="MsoNormal">But the BGP session to carry IPsec
        configurations is via BGP management session, which is
        completely isolated form the dataplane BGP sessions. </p>
    </blockquote>
    <br>
    I'm not sure I have the whole context, but the question seems to be
    whether it could ever be safe to use BGP to distribute secret keys.<br>
    <br>
    Presumably:<br>
    <br>
    - The keys would be carried in an attribute that can only be
    attached by UPDATEs of a specified AFI/SAFI, where the specified
    AFI/SAFI is only used to carry management/configuration information.<br>
    <br>
    - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that
    are adequately secured so as to provide privacy, integrity and
    authentication.<br>
    <br>
    - The UPDATEs would carry the NO_ADVERTISE community (to make sure
    they are not propagated further).<br>
    <br>
    - None of the BGP systems involved would allow any sort of "BGP
    monitoring" that might expose the unencrypted contents of the
    UPDATEs.<br>
    <br>
    In this scenario, I don't think it matters whether the secure BGP
    session also carries other AFI/SAFIs.<br>
    <br>
    The privacy properties of this scenario are pretty good, in theory,
    but I don't think they are really good enough for distributing
    secret keys.<br>
    <br>
    - Once you're using BGP to distribute information, it is inevitable
    that someone will decide to remove the "NO_ADVERTISE" and allow the
    information to be propagated through intermediate nodes (RRs or
    ASBRs) to the actual target node.  After all, one of the main values
    of using BGP to distribute stuff is that you get a big distribution
    system.  Even if all the intermediate nodes are trusted and all the
    intermediate BGP sessions have adequate
    privacy/integrity/authentication, you still wouldn't want to expose
    the secret keys to those nodes.  You might trust those nodes to see
    all the routing information, and even to see most of the management
    information, but you probably don't want them to see all the secret
    keys.  And you probably don't want the secret keys stored in the
    clear on those intermediate nodes.<br>
    <br>
    - I would worry about BGP monitoring procedures creating a backdoor
    through which the secret keys would be exposed.  <br>
    <br>
    - No matter how careful you are, when you use BGP you can be pretty
    sure that your UPDATEs will end up somewhere they're not supposed to
    go.  It's just too easy to make mistakes.  <br>
    So I don't think I'd try to do dynamic keying by attaching the
    actual keys to BGP UPDATEs.  At most I'd use BGP to distribute
    parameters that could then be used by something like IKEv2 to
    actually fetch the secret keys.<br>
    <br>
  </body>
</html>

--------------89DFA5C19FD77CE743BE42B6--


From nobody Thu Aug 16 15:24:00 2018
Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CC130DF3; Thu, 16 Aug 2018 15:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.01
X-Spam-Level: 
X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 eqVyRPSj4DfG; Thu, 16 Aug 2018 15:23:48 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 363B8130DEA; Thu, 16 Aug 2018 15:23:48 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id f23-v6so3503807edr.11; Thu, 16 Aug 2018 15:23:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J69/U6cFH3uO6q1ZlBlOIddtfrgzCpuoahIMUx2TcI4=; b=KHZCBv56h1wWoXdW3m4wNesq0S4cIqlQ4ANVc251oy//oXLlwuGSMf+AIA04sIncxj Wyi1nNGIPGvDhb4tf1Ya3hYDVb1v/adzRE3rNGEWXCVKqli4b2NN7hrVGGReD4L+oiWi EBCtUW6NUI78OVQcYlkRaL3ySvtNuufO6Qsf7C2Ax89dYdnGSA2nXz6SrRMOqywIzS5H SmqyZLvPwgsPsSYSLvALGo3+vqPKNboe2k7bBOL1HHXtkWCgtBAe7JpIiuJ0+iWQ7Tya KbQ0uSavQ9/K64145s8oywxcLGsvOASAW4P/pxkscKiRf4HAmFRgqRNo2C7lOsdKjjFT k/ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J69/U6cFH3uO6q1ZlBlOIddtfrgzCpuoahIMUx2TcI4=; b=jMIbad2CtOEUTT/td+FuBnRknRwxgucBUoWAbudu3LcWQapV58jrancvucWoFdBmcR v4iuWEB0wvO+7iROOpmV3XZvL6KV5c10KQW9Sbl6hZ8oeDaQMk6wx+D8+agGk8p/6RL3 8OYDW/EdWh/fMrGA3mOYCTNxA9mFSl/Jqqlmg5ioBuXOMMjnu3xdCuYWw2klKB7nz8tA 4NGorYb2pf2OBgEE8qKikFjSi2ReI01H/huwzVWM4pzZeTd0PkEEfoUdWiM6Aj+5y3s1 i1rTHnqQmiJhy6c+8CERB0Ks7O8xH2rtaJ3xmaNekMJ4e5RjDMNOuUpOERDCgn1Ht6eS ARlw==
X-Gm-Message-State: AOUpUlG2nSgMYl+8XXopw6Ey0gJeJu2T/HiovKrukCBX0HfqAm+IAHCa HeLl3Combr58uddiNYRvI3T0PBAblLpMww50qNU=
X-Google-Smtp-Source: AA+uWPxdkEXM0PAEBVCYlsmSVeXhABqg0YkcVVPl31asSx0JJ6SXlUOXzNP+ew7mrkpC4/jv9e5Ia3MLHupMQ7f85Sk=
X-Received: by 2002:a50:94c4:: with SMTP id t4-v6mr37790048eda.128.1534458226817;  Thu, 16 Aug 2018 15:23:46 -0700 (PDT)
MIME-Version: 1.0
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net>
In-Reply-To: <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net>
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Date: Thu, 16 Aug 2018 15:23:35 -0700
Message-ID: <CAFAzdPWQcDFDB1jFJgtWDGOnRsJVkqg01gFSkfqzi_0XmofdCg@mail.gmail.com>
To: Eric C Rosen <erosen@juniper.net>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000883f90057394e575"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Zu4_IU-nn3IP30t8ABIzNF8jiHk>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 22:23:52 -0000

--000000000000883f90057394e575
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Eric for your analysis!

Linda - Eric confirmed wg feedback and explained in great details why using
BGP for key distribution (while appealing) is not a great idea, you could
add to that use of group keys, so in case of a breach, whole group becomes
compromised (obviously there=E2=80=99s more to that, greatly generalized
statement). Let=E2=80=99s move on.

Thanks,
Jeff


On Thu, Aug 16, 2018 at 12:59 Eric C Rosen <erosen@juniper.net> wrote:

> On 8/13/2018 3:26 PM, Linda Dunbar wrote:
>
> One of the comments to
> https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/
> <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.=
org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=3DDwMFAg&c=3DHAkYuh63rsu=
hr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0k=
G0VNo&m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=3D9xbKYj5fP6Jv93coe=
5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=3D>
> the In RTGwg session of IETF102 is that using BGP session to pass
> configuration keys for IPsec can be risky even if the path between RR &
> node is secure (say via TLS) due to BGP route leak (Hijack).
>
> But the BGP session to carry IPsec configurations is via BGP management
> session, which is completely isolated form the dataplane BGP sessions.
>
>
> I'm not sure I have the whole context, but the question seems to be
> whether it could ever be safe to use BGP to distribute secret keys.
>
> Presumably:
>
> - The keys would be carried in an attribute that can only be attached by
> UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only use=
d
> to carry management/configuration information.
>
> - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are
> adequately secured so as to provide privacy, integrity and authentication=
.
>
> - The UPDATEs would carry the NO_ADVERTISE community (to make sure they
> are not propagated further).
>
> - None of the BGP systems involved would allow any sort of "BGP
> monitoring" that might expose the unencrypted contents of the UPDATEs.
>
> In this scenario, I don't think it matters whether the secure BGP session
> also carries other AFI/SAFIs.
>
> The privacy properties of this scenario are pretty good, in theory, but I
> don't think they are really good enough for distributing secret keys.
>
> - Once you're using BGP to distribute information, it is inevitable that
> someone will decide to remove the "NO_ADVERTISE" and allow the informatio=
n
> to be propagated through intermediate nodes (RRs or ASBRs) to the actual
> target node.  After all, one of the main values of using BGP to distribut=
e
> stuff is that you get a big distribution system.  Even if all the
> intermediate nodes are trusted and all the intermediate BGP sessions have
> adequate privacy/integrity/authentication, you still wouldn't want to
> expose the secret keys to those nodes.  You might trust those nodes to se=
e
> all the routing information, and even to see most of the management
> information, but you probably don't want them to see all the secret keys.
> And you probably don't want the secret keys stored in the clear on those
> intermediate nodes.
>
> - I would worry about BGP monitoring procedures creating a backdoor
> through which the secret keys would be exposed.
>
> - No matter how careful you are, when you use BGP you can be pretty sure
> that your UPDATEs will end up somewhere they're not supposed to go.  It's
> just too easy to make mistakes.
> So I don't think I'd try to do dynamic keying by attaching the actual key=
s
> to BGP UPDATEs.  At most I'd use BGP to distribute parameters that could
> then be used by something like IKEv2 to actually fetch the secret keys.
>
>

--000000000000883f90057394e575
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks Eric for your analysis!<br><br>Linda - Eric confirmed wg feedback an=
d explained in great details why using BGP for key distribution (while appe=
aling) is not a great idea, you could add to that use of group keys, so in =
case of a breach, whole group becomes compromised (obviously there=E2=80=99=
s more to that, greatly generalized statement). Let=E2=80=99s move on.<br><=
br>Thanks,<br>Jeff<br><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Thu, Aug 16, 2018 at 12:59 Eric C Rosen &lt;<a href=3D"mailto:erosen@juni=
per.net">erosen@juniper.net</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
 =20
   =20
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF">
    On 8/13/2018 3:26 PM, Linda Dunbar wrote:<br>
    <blockquote type=3D"cite">
      <p class=3D"MsoNormal">One of the comments to <a href=3D"https://urld=
efense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2=
Ddm-2Dnet2cloud-2Dgap-2Danalysis_&amp;d=3DDwMFAg&amp;c=3DHAkYuh63rsuhr6Scbf=
h0UjBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0V=
No&amp;m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&amp;s=3D9xbKYj5fP6Jv=
93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&amp;e=3D" target=3D"_blank">
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/</a>
        the In RTGwg session of IETF102 is that using BGP session to
        pass configuration keys for IPsec can be risky even if the path
        between RR &amp; node is secure (say via TLS) due to BGP route
        leak (Hijack). <u></u><u></u></p>
      <p class=3D"MsoNormal">But the BGP session to carry IPsec
        configurations is via BGP management session, which is
        completely isolated form the dataplane BGP sessions. </p>
    </blockquote>
    <br>
    I&#39;m not sure I have the whole context, but the question seems to be
    whether it could ever be safe to use BGP to distribute secret keys.<br>
    <br>
    Presumably:<br>
    <br>
    - The keys would be carried in an attribute that can only be
    attached by UPDATEs of a specified AFI/SAFI, where the specified
    AFI/SAFI is only used to carry management/configuration information.<br=
>
    <br>
    - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that
    are adequately secured so as to provide privacy, integrity and
    authentication.<br>
    <br>
    - The UPDATEs would carry the NO_ADVERTISE community (to make sure
    they are not propagated further).<br>
    <br>
    - None of the BGP systems involved would allow any sort of &quot;BGP
    monitoring&quot; that might expose the unencrypted contents of the
    UPDATEs.<br>
    <br>
    In this scenario, I don&#39;t think it matters whether the secure BGP
    session also carries other AFI/SAFIs.<br>
    <br>
    The privacy properties of this scenario are pretty good, in theory,
    but I don&#39;t think they are really good enough for distributing
    secret keys.<br>
    <br>
    - Once you&#39;re using BGP to distribute information, it is inevitable
    that someone will decide to remove the &quot;NO_ADVERTISE&quot; and all=
ow the
    information to be propagated through intermediate nodes (RRs or
    ASBRs) to the actual target node.=C2=A0 After all, one of the main valu=
es
    of using BGP to distribute stuff is that you get a big distribution
    system.=C2=A0 Even if all the intermediate nodes are trusted and all th=
e
    intermediate BGP sessions have adequate
    privacy/integrity/authentication, you still wouldn&#39;t want to expose
    the secret keys to those nodes.=C2=A0 You might trust those nodes to se=
e
    all the routing information, and even to see most of the management
    information, but you probably don&#39;t want them to see all the secret
    keys.=C2=A0 And you probably don&#39;t want the secret keys stored in t=
he
    clear on those intermediate nodes.<br>
    <br>
    - I would worry about BGP monitoring procedures creating a backdoor
    through which the secret keys would be exposed.=C2=A0 <br>
    <br>
    - No matter how careful you are, when you use BGP you can be pretty
    sure that your UPDATEs will end up somewhere they&#39;re not supposed t=
o
    go.=C2=A0 It&#39;s just too easy to make mistakes.=C2=A0 <br>
    So I don&#39;t think I&#39;d try to do dynamic keying by attaching the
    actual keys to BGP UPDATEs.=C2=A0 At most I&#39;d use BGP to distribute
    parameters that could then be used by something like IKEv2 to
    actually fetch the secret keys.<br>
    <br>
  </div>

</blockquote></div>

--000000000000883f90057394e575--


From nobody Thu Aug 16 15:59:41 2018
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18567130E23; Thu, 16 Aug 2018 15:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level: 
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 swjCGjieqxFO; Thu, 16 Aug 2018 15:59:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 DE4C0130E11; Thu, 16 Aug 2018 15:59:28 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 558F4302BDC31; Thu, 16 Aug 2018 23:59:25 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 16 Aug 2018 23:59:26 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML702-CHM.china.huawei.com ([169.254.4.45]) with mapi id 14.03.0399.000; Thu, 16 Aug 2018 15:59:24 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Eric C Rosen <erosen@juniper.net>, "shares@ndzh.com" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, Jeff Tantsura <jefftant.ietf@gmail.com>, RTGWG <rtgwg@ietf.org>
Thread-Topic: Preventing BGP Route leak (Hijack) for Management Channel BGP session
Thread-Index: AdQzO4r0PzSwhpZvSCmMNMmO/EiBoACmr3EAAAjTVEA=
Date: Thu, 16 Aug 2018 22:59:24 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net>
In-Reply-To: <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.118]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0DC48Fsjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MZfp8ZduK2m3CCkQ4YJPHLLO-Tg>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 22:59:32 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DC48Fsjceml521mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Eric,

Thank you very much for the detailed explanation.

I meant to ask about using BGP UPDATEs of a unique AFI/SAFI to distribute t=
he "Public Keys" and individual "Nonce" to all the CPEs. Just like IKE (whe=
re peers exchange public key over internet), now the Public keys are exchan=
ged between peers via RR (Controller). With this approach, the CPEs can off=
load the Peer Authentication job to Controller.

IPsec's  Diffie-Hellman algorithm use "Public Key" and CPE's Private Key to=
 compute the actual Security Association.

In your draft-rosen-bess-secure-l3vpn-01, you have BLACK BGP session and RE=
D BGP session, and emphasized on how BLACK BGP not leaking routes to RED BG=
P. I want to know if we can do the same for Management BGP session, i.e. re=
quiring Data Plan BGP session to be completely separate from the Management=
 Plane BGP session, is it Okay?

Thanks, Linda Dunbar



From: Eric C Rosen [mailto:erosen@juniper.net]
Sent: Thursday, August 16, 2018 2:59 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; shares@ndzh.com; idr@ietf.org; =
Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <rtgwg@ietf.org>
Subject: Re: Preventing BGP Route leak (Hijack) for Management Channel BGP =
session

On 8/13/2018 3:26 PM, Linda Dunbar wrote:

One of the comments to https://datatracker.ietf.org/doc/draft-dm-net2cloud-=
gap-analysis/<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatr=
acker.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=3DDwMFAg&c=3D=
HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJ=
XQQswyu3F0kG0VNo&m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=3D9xbKYj=
5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=3D> the In RTGwg session of IETF102=
 is that using BGP session to pass configuration keys for IPsec can be risk=
y even if the path between RR & node is secure (say via TLS) due to BGP rou=
te leak (Hijack).
But the BGP session to carry IPsec configurations is via BGP management ses=
sion, which is completely isolated form the dataplane BGP sessions.

I'm not sure I have the whole context, but the question seems to be whether=
 it could ever be safe to use BGP to distribute secret keys.

Presumably:

- The keys would be carried in an attribute that can only be attached by UP=
DATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used to=
 carry management/configuration information.

- UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are adeq=
uately secured so as to provide privacy, integrity and authentication.

- The UPDATEs would carry the NO_ADVERTISE community (to make sure they are=
 not propagated further).

- None of the BGP systems involved would allow any sort of "BGP monitoring"=
 that might expose the unencrypted contents of the UPDATEs.

In this scenario, I don't think it matters whether the secure BGP session a=
lso carries other AFI/SAFIs.

The privacy properties of this scenario are pretty good, in theory, but I d=
on't think they are really good enough for distributing secret keys.

- Once you're using BGP to distribute information, it is inevitable that so=
meone will decide to remove the "NO_ADVERTISE" and allow the information to=
 be propagated through intermediate nodes (RRs or ASBRs) to the actual targ=
et node.  After all, one of the main values of using BGP to distribute stuf=
f is that you get a big distribution system.  Even if all the intermediate =
nodes are trusted and all the intermediate BGP sessions have adequate priva=
cy/integrity/authentication, you still wouldn't want to expose the secret k=
eys to those nodes.  You might trust those nodes to see all the routing inf=
ormation, and even to see most of the management information, but you proba=
bly don't want them to see all the secret keys.  And you probably don't wan=
t the secret keys stored in the clear on those intermediate nodes.

- I would worry about BGP monitoring procedures creating a backdoor through=
 which the secret keys would be exposed.

- No matter how careful you are, when you use BGP you can be pretty sure th=
at your UPDATEs will end up somewhere they're not supposed to go.  It's jus=
t too easy to make mistakes.
So I don't think I'd try to do dynamic keying by attaching the actual keys =
to BGP UPDATEs.  At most I'd use BGP to distribute parameters that could th=
en be used by something like IKEv2 to actually fetch the secret keys.

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DC48Fsjceml521mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;
	color:black;}
h2
	{mso-style-priority:9;
	mso-style-link:"Heading 2 Char";
	margin-top:2.0pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:0in;
	margin-bottom:.0001pt;
	page-break-after:avoid;
	font-size:13.0pt;
	font-family:"Calibri Light",sans-serif;
	color:#2E74B5;
	font-weight:normal;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.Heading2Char
	{mso-style-name:"Heading 2 Char";
	mso-style-priority:9;
	mso-style-link:"Heading 2";
	font-family:"Calibri Light",sans-serif;
	color:#2E74B5;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Eric,
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Thank you very much for the detailed =
explanation.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">I meant to ask about using BGP
</span>UPDATEs of a unique AFI/SAFI <span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif;color:#1F497D">
to distribute the &#8220;Public Keys&#8221; and individual &#8220;Nonce&#82=
21; to all the CPEs. Just like IKE (where peers exchange public key over in=
ternet), now the Public keys are exchanged between peers via RR (Controller=
). With this approach, the CPEs can offload the Peer Authentication
 job to Controller. <o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">IPsec&#8217;s &nbsp;Diffie-Hellman&nb=
sp;algorithm use &#8220;Public Key&#8221; and CPE&#8217;s Private Key to co=
mpute the actual Security Association.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">In your draft-rosen-bess-secure-l3vpn=
-01, you have BLACK BGP session and RED BGP session, and emphasized on how =
BLACK BGP not leaking routes to RED BGP. I want
 to know if we can do the same for Management BGP session, i.e. requiring D=
ata Plan BGP session to be completely separate from the Management Plane BG=
P session, is it Okay?
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Thanks, Linda Dunbar<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><a name=3D"_MailEndCompose"><span style=3D"font-size=
:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbs=
p;</o:p></span></a></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:windowtext">From:</span></b><span style=3D"=
font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:windowtex=
t"> Eric C Rosen [mailto:erosen@juniper.net]
<br>
<b>Sent:</b> Thursday, August 16, 2018 2:59 PM<br>
<b>To:</b> Linda Dunbar &lt;linda.dunbar@huawei.com&gt;; shares@ndzh.com; i=
dr@ietf.org; Jeff Tantsura &lt;jefftant.ietf@gmail.com&gt;; RTGWG &lt;rtgwg=
@ietf.org&gt;<br>
<b>Subject:</b> Re: Preventing BGP Route leak (Hijack) for Management Chann=
el BGP session<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">On 8/13/2018 3:26 PM, Linda Dunbar wrote:<br>
<br>
<o:p></o:p></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">One of the comments to
<a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrack=
er.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&amp;d=3DDwMFAg&amp=
;c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OO=
cCJCQQAwJXQQswyu3F0kG0VNo&amp;m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRz=
r0&amp;s=3D9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&amp;e=3D">
https://datatracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/</a> the I=
n RTGwg session of IETF102 is that using BGP session to pass configuration =
keys for IPsec can be risky even if the path between RR &amp; node is secur=
e (say via TLS) due to BGP route leak
 (Hijack). <o:p></o:p></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto">But the BGP session to carry IPsec configurations is via BGP manag=
ement session, which is completely isolated form the dataplane BGP sessions=
.
<o:p></o:p></p>
</blockquote>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
I'm not sure I have the whole context, but the question seems to be whether=
 it could ever be safe to use BGP to distribute secret keys.<br>
<br>
Presumably:<br>
<br>
- The keys would be carried in an attribute that can only be attached by UP=
DATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used to=
 carry management/configuration information.<br>
<br>
- UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are adeq=
uately secured so as to provide privacy, integrity and authentication.<br>
<br>
- The UPDATEs would carry the NO_ADVERTISE community (to make sure they are=
 not propagated further).<br>
<br>
- None of the BGP systems involved would allow any sort of &quot;BGP monito=
ring&quot; that might expose the unencrypted contents of the UPDATEs.<br>
<br>
In this scenario, I don't think it matters whether the secure BGP session a=
lso carries other AFI/SAFIs.<br>
<br>
The privacy properties of this scenario are pretty good, in theory, but I d=
on't think they are really good enough for distributing secret keys.<br>
<br>
- Once you're using BGP to distribute information, it is inevitable that so=
meone will decide to remove the &quot;NO_ADVERTISE&quot; and allow the info=
rmation to be propagated through intermediate nodes (RRs or ASBRs) to the a=
ctual target node.&nbsp; After all, one of the
 main values of using BGP to distribute stuff is that you get a big distrib=
ution system.&nbsp; Even if all the intermediate nodes are trusted and all =
the intermediate BGP sessions have adequate privacy/integrity/authenticatio=
n, you still wouldn't want to expose
 the secret keys to those nodes.&nbsp; You might trust those nodes to see a=
ll the routing information, and even to see most of the management informat=
ion, but you probably don't want them to see all the secret keys.&nbsp; And=
 you probably don't want the secret keys stored
 in the clear on those intermediate nodes.<br>
<br>
- I would worry about BGP monitoring procedures creating a backdoor through=
 which the secret keys would be exposed.&nbsp;
<br>
<br>
- No matter how careful you are, when you use BGP you can be pretty sure th=
at your UPDATEs will end up somewhere they're not supposed to go.&nbsp; It'=
s just too easy to make mistakes.&nbsp;
<br>
So I don't think I'd try to do dynamic keying by attaching the actual keys =
to BGP UPDATEs.&nbsp; At most I'd use BGP to distribute parameters that cou=
ld then be used by something like IKEv2 to actually fetch the secret keys.<=
o:p></o:p></p>
</div>
</body>
</html>

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DC48Fsjceml521mbxchi_--


From nobody Fri Aug 17 02:20:13 2018
Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A880A130E54 for <idr@ietfa.amsl.com>; Fri, 17 Aug 2018 02:20:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 xzmS-QKyFSLH for <idr@ietfa.amsl.com>; Fri, 17 Aug 2018 02:20:08 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 E74A2129385 for <idr@ietf.org>; Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id e19-v6so8024547qtp.8 for <idr@ietf.org>; Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MS1FvaIJsccB8YujLein1uEBANCWD6PvPf78C4EZpfA=; b=aV4NTouL6Nc8ezAC18M7LeOR9ooTqhuUfc3qQecdeMsB8d8KYVMrszF9uRvtWM4CdN nncZFK05au1G05Yhr5qlxvicc/oYC1ZyLZVjgXvKnhbo1mwUsdygkEfkty2C03jGItxL Fsntu3nL22AfZqd3tseLLYt9B4cNmJGOVy5kAw2jxaKNdTOPYrUUgreee732n8XrfV4l 3DnplvjBIveoybhmIcZUrOXmI0aQU5h8N91cLuBGNmlLaK9zDGaG/nKX9lOtta9slnLV 4hZWFbktkW4c7BC+jrZEMnwKVTH4Tu5Npin1C7qGGqXFgGUnrsSWvHv2xIH0i/Q65h6u NX4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MS1FvaIJsccB8YujLein1uEBANCWD6PvPf78C4EZpfA=; b=buo4smYO0jpXW4cLf6ii7XT3/MZsvWTRLXVHrj2lBZZEucoro0Hvalyd2UIJH0LiEh nVGYTmOIFJ0/Yl39Y82k2iXEOfFw36Q0EWzjPc30/hgvnVF5gYYrrjPFx54wDlg939ma tXKbSCW0VYtrifd41C7TC6rbdgd+MGS/aE5RmtyR/mTtVXBFjbolxLzRnkPS8cNUSrF6 3rPeDzVJ2erwVTH9aDnmb+t2Wm3uzvgNzJn9T1NnJQnKNbAFVi8VhgoluH+BmvLwMOt8 69651jKpqR/+YhvP4TcSj4B98dR/rOhYuC16nn/q9GIGEfpuMTT6CQZMz+E2POBG6vUj zjdg==
X-Gm-Message-State: AOUpUlEVI/ju3YqnrsjDgn921sXMsLjb4Rx+Z/s+PtgqjUew/IjjA+iZ TJnhs3RQr8GXHEnW8t0qUSXYZEhho56glm+VUI37mw==
X-Google-Smtp-Source: AA+uWPz1vmKBbkD6u/y6Oo63R0mUg5E30uNPYeKDqo5HiCMam241FIdJLA9TfYSy4M7stHMd6CKK+5S4V0fm1+dR2JY=
X-Received: by 2002:a0c:95ad:: with SMTP id s42-v6mr30191174qvs.18.1534497607067;  Fri, 17 Aug 2018 02:20:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:afd4:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 02:20:06 -0700 (PDT)
X-Originating-IP: [83.28.116.46]
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net> <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 17 Aug 2018 11:20:06 +0200
Message-ID: <CAOj+MMH-LmcnB60qWftf1fPjLXpFt1MdVRJKw4CLg6qyBef9Zg@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c740bc05739e1015"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Lx1oYfA0Yo2xzKy9Mw40cDGqs1I>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 09:20:12 -0000

--000000000000c740bc05739e1015
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Linda,

> requiring Data Plan BGP session to be completely separate from the
Management Plane BGP session, is it Okay?

As I mentioned offline there is no distinction in BGP for data plane BGP
session vs Mgmt Plane BGP session.

BGP session is a BGP session - pure TCP stream of packets which is pretty
trivial to intercept, decode, hijack, etc ....

Moreover BGP messages are designed to be flooded everywhere in a p2mp
fashion. Even if you add "NO-ADVERTISE" BGP community to it - communities
can get stripped automatically on any BGP speaker. Hence you clean your
sole safety protection.

The question I would like to state and understood - why are you trying so
hard to use BGP for IPSec secret key distribution ? Is this only due to the
fact that you have it there ? Wasn't IKE and now improved IKEv2
specifically designed to do just that ? Any reason you don't want to use it
?

Thx,
R.



On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <linda.dunbar@huawei.com>
wrote:

> Eric,
>
>
>
> Thank you very much for the detailed explanation.
>
>
>
> I meant to ask about using BGP UPDATEs of a unique AFI/SAFI to distribute
> the =E2=80=9CPublic Keys=E2=80=9D and individual =E2=80=9CNonce=E2=80=9D =
to all the CPEs. Just like IKE
> (where peers exchange public key over internet), now the Public keys are
> exchanged between peers via RR (Controller). With this approach, the CPEs
> can offload the Peer Authentication job to Controller.
>
>
>
> IPsec=E2=80=99s  Diffie-Hellman algorithm use =E2=80=9CPublic Key=E2=80=
=9D and CPE=E2=80=99s Private Key
> to compute the actual Security Association.
>
>
>
> In your draft-rosen-bess-secure-l3vpn-01, you have BLACK BGP session and
> RED BGP session, and emphasized on how BLACK BGP not leaking routes to RE=
D
> BGP. I want to know if we can do the same for Management BGP session, i.e=
.
> requiring Data Plan BGP session to be completely separate from the
> Management Plane BGP session, is it Okay?
>
>
>
> Thanks, Linda Dunbar
>
>
>
>
>
>
>
> *From:* Eric C Rosen [mailto:erosen@juniper.net]
> *Sent:* Thursday, August 16, 2018 2:59 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>; shares@ndzh.com;
> idr@ietf.org; Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <
> rtgwg@ietf.org>
> *Subject:* Re: Preventing BGP Route leak (Hijack) for Management Channel
> BGP session
>
>
>
> On 8/13/2018 3:26 PM, Linda Dunbar wrote:
>
> One of the comments to https://datatracker.ietf.org/
> doc/draft-dm-net2cloud-gap-analysis/
> <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.=
org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&d=3DDwMFAg&c=3DHAkYuh63rsu=
hr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0k=
G0VNo&m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&s=3D9xbKYj5fP6Jv93coe=
5g-lfzpp0L0bK0GyrlB91Ry3Sw&e=3D>
> the In RTGwg session of IETF102 is that using BGP session to pass
> configuration keys for IPsec can be risky even if the path between RR &
> node is secure (say via TLS) due to BGP route leak (Hijack).
>
> But the BGP session to carry IPsec configurations is via BGP management
> session, which is completely isolated form the dataplane BGP sessions..
>
>
> I'm not sure I have the whole context, but the question seems to be
> whether it could ever be safe to use BGP to distribute secret keys.
>
> Presumably:
>
> - The keys would be carried in an attribute that can only be attached by
> UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only use=
d
> to carry management/configuration information.
>
> - UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are
> adequately secured so as to provide privacy, integrity and authentication=
.
>
> - The UPDATEs would carry the NO_ADVERTISE community (to make sure they
> are not propagated further).
>
> - None of the BGP systems involved would allow any sort of "BGP
> monitoring" that might expose the unencrypted contents of the UPDATEs.
>
> In this scenario, I don't think it matters whether the secure BGP session
> also carries other AFI/SAFIs.
>
> The privacy properties of this scenario are pretty good, in theory, but I
> don't think they are really good enough for distributing secret keys.
>
> - Once you're using BGP to distribute information, it is inevitable that
> someone will decide to remove the "NO_ADVERTISE" and allow the informatio=
n
> to be propagated through intermediate nodes (RRs or ASBRs) to the actual
> target node.  After all, one of the main values of using BGP to distribut=
e
> stuff is that you get a big distribution system.  Even if all the
> intermediate nodes are trusted and all the intermediate BGP sessions have
> adequate privacy/integrity/authentication, you still wouldn't want to
> expose the secret keys to those nodes.  You might trust those nodes to se=
e
> all the routing information, and even to see most of the management
> information, but you probably don't want them to see all the secret keys.
> And you probably don't want the secret keys stored in the clear on those
> intermediate nodes.
>
> - I would worry about BGP monitoring procedures creating a backdoor
> through which the secret keys would be exposed.
>
> - No matter how careful you are, when you use BGP you can be pretty sure
> that your UPDATEs will end up somewhere they're not supposed to go.  It's
> just too easy to make mistakes.
> So I don't think I'd try to do dynamic keying by attaching the actual key=
s
> to BGP UPDATEs.  At most I'd use BGP to distribute parameters that could
> then be used by something like IKEv2 to actually fetch the secret keys.
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>

--000000000000c740bc05739e1015
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Linda,<div><br></div><div>

<span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-siz=
e:14.6667px;background-color:rgb(255,255,255);text-decoration-style:initial=
;text-decoration-color:initial;float:none;display:inline">&gt; requiring Da=
ta Plan BGP session to be completely separate from the Management Plane BGP=
 session, is it Okay?</span>

<br></div><div><br></div><div>As I mentioned offline there is no distinctio=
n in BGP for data plane BGP session vs Mgmt Plane BGP session.=C2=A0</div><=
div><br></div><div>BGP session is a BGP session - pure TCP stream of packet=
s which is pretty trivial to intercept, decode, hijack, etc ....=C2=A0</div=
><div><br></div><div>Moreover BGP messages are designed to be flooded every=
where in a p2mp fashion. Even if you add &quot;NO-ADVERTISE&quot; BGP commu=
nity to it - communities can get stripped automatically on any BGP speaker.=
 Hence you clean your sole safety protection.=C2=A0</div><div><br></div><di=
v>The question I would like to state and understood - why are you trying so=
 hard to use BGP for IPSec secret key distribution ? Is this only due to th=
e fact that you have it there ? Wasn&#39;t IKE and now improved IKEv2 speci=
fically designed to do just that ? Any reason you don&#39;t want to use it =
?=C2=A0</div><div><br></div><div>Thx,</div><div>R.</div><div><br></div><div=
><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:linda.dunbar@huawei.com" target=3D"_blank">linda.dunbar@huawei.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div bgcolor=3D"white" lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"m_-8787313158689100800WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Eric,
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Thank you very much for the detailed =
explanation.
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">I meant to ask about using BGP
</span>UPDATEs of a unique AFI/SAFI <span style=3D"font-size:11.0pt;font-fa=
mily:&quot;Calibri&quot;,sans-serif;color:#1f497d">
to distribute the =E2=80=9CPublic Keys=E2=80=9D and individual =E2=80=9CNon=
ce=E2=80=9D to all the CPEs. Just like IKE (where peers exchange public key=
 over internet), now the Public keys are exchanged between peers via RR (Co=
ntroller). With this approach, the CPEs can offload the Peer Authentication
 job to Controller. <u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">IPsec=E2=80=99s =C2=A0Diffie-Hellman=
=C2=A0algorithm use =E2=80=9CPublic Key=E2=80=9D and CPE=E2=80=99s Private =
Key to compute the actual Security Association.
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">In your draft-rosen-bess-secure-l3vpn=
-<wbr>01, you have BLACK BGP session and RED BGP session, and emphasized on=
 how BLACK BGP not leaking routes to RED BGP. I want
 to know if we can do the same for Management BGP session, i.e. requiring D=
ata Plan BGP session to be completely separate from the Management Plane BG=
P session, is it Okay?
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d">Thanks, Linda Dunbar<u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1f497d"><u></u>=C2=A0<u></u></span></p>
<p class=3D"MsoNormal"><a name=3D"m_-8787313158689100800__MailEndCompose"><=
span style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;c=
olor:#1f497d"><u></u>=C2=A0<u></u></span></a></p>
<div>
<div style=3D"border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:windowtext">From:</span></b><span style=3D"=
font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:windowtex=
t"> Eric C Rosen [mailto:<a href=3D"mailto:erosen@juniper.net" target=3D"_b=
lank">erosen@juniper.net</a>]
<br>
<b>Sent:</b> Thursday, August 16, 2018 2:59 PM<br>
<b>To:</b> Linda Dunbar &lt;<a href=3D"mailto:linda.dunbar@huawei.com" targ=
et=3D"_blank">linda.dunbar@huawei.com</a>&gt;; <a href=3D"mailto:shares@ndz=
h.com" target=3D"_blank">shares@ndzh.com</a>; <a href=3D"mailto:idr@ietf.or=
g" target=3D"_blank">idr@ietf.org</a>; Jeff Tantsura &lt;<a href=3D"mailto:=
jefftant.ietf@gmail.com" target=3D"_blank">jefftant.ietf@gmail.com</a>&gt;;=
 RTGWG &lt;<a href=3D"mailto:rtgwg@ietf.org" target=3D"_blank">rtgwg@ietf.o=
rg</a>&gt;<span class=3D""><br>
<b>Subject:</b> Re: Preventing BGP Route leak (Hijack) for Management Chann=
el BGP session<u></u><u></u></span></span></p>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">On 8/13/2018 3:26 PM, Linda Dunbar wrote:<br>
<br>
<u></u><u></u></p>
<blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"><span class=3D""=
>
<p class=3D"MsoNormal">One of the comments to
<a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatrack=
er.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&amp;d=3DDwMFAg&amp=
;c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OO=
cCJCQQAwJXQQswyu3F0kG0VNo&amp;m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRz=
r0&amp;s=3D9xbKYj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&amp;e=3D" target=3D"=
_blank">
https://datatracker.ietf.org/<wbr>doc/draft-dm-net2cloud-gap-<wbr>analysis/=
</a> the In RTGwg session of IETF102 is that using BGP session to pass conf=
iguration keys for IPsec can be risky even if the path between RR &amp; nod=
e is secure (say via TLS) due to BGP route leak
 (Hijack). <u></u><u></u></p>
</span><p class=3D"MsoNormal">But the BGP session to carry IPsec configurat=
ions is via BGP management session, which is completely isolated form the d=
ataplane BGP sessions..
<u></u><u></u></p>
</blockquote><span class=3D"">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
I&#39;m not sure I have the whole context, but the question seems to be whe=
ther it could ever be safe to use BGP to distribute secret keys.<br>
<br>
Presumably:<br>
<br>
- The keys would be carried in an attribute that can only be attached by UP=
DATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used to=
 carry management/configuration information.<br>
<br>
- UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are adeq=
uately secured so as to provide privacy, integrity and authentication.<br>
<br>
- The UPDATEs would carry the NO_ADVERTISE community (to make sure they are=
 not propagated further).<br>
<br>
- None of the BGP systems involved would allow any sort of &quot;BGP monito=
ring&quot; that might expose the unencrypted contents of the UPDATEs.<br>
<br>
In this scenario, I don&#39;t think it matters whether the secure BGP sessi=
on also carries other AFI/SAFIs.<br>
<br>
The privacy properties of this scenario are pretty good, in theory, but I d=
on&#39;t think they are really good enough for distributing secret keys.<br=
>
<br>
- Once you&#39;re using BGP to distribute information, it is inevitable tha=
t someone will decide to remove the &quot;NO_ADVERTISE&quot; and allow the =
information to be propagated through intermediate nodes (RRs or ASBRs) to t=
he actual target node.=C2=A0 After all, one of the
 main values of using BGP to distribute stuff is that you get a big distrib=
ution system.=C2=A0 Even if all the intermediate nodes are trusted and all =
the intermediate BGP sessions have adequate privacy/integrity/<wbr>authenti=
cation, you still wouldn&#39;t want to expose
 the secret keys to those nodes.=C2=A0 You might trust those nodes to see a=
ll the routing information, and even to see most of the management informat=
ion, but you probably don&#39;t want them to see all the secret keys.=C2=A0=
 And you probably don&#39;t want the secret keys stored
 in the clear on those intermediate nodes.<br>
<br>
- I would worry about BGP monitoring procedures creating a backdoor through=
 which the secret keys would be exposed.=C2=A0
<br>
<br>
- No matter how careful you are, when you use BGP you can be pretty sure th=
at your UPDATEs will end up somewhere they&#39;re not supposed to go.=C2=A0=
 It&#39;s just too easy to make mistakes.=C2=A0
<br>
So I don&#39;t think I&#39;d try to do dynamic keying by attaching the actu=
al keys to BGP UPDATEs.=C2=A0 At most I&#39;d use BGP to distribute paramet=
ers that could then be used by something like IKEv2 to actually fetch the s=
ecret keys.<u></u><u></u></p>
</span></div>
</div>

<br>______________________________<wbr>_________________<br>
rtgwg mailing list<br>
<a href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/rtgwg" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/<wbr>listinfo/rtgwg</a><br>
<br></blockquote></div><br></div>

--000000000000c740bc05739e1015--


From nobody Fri Aug 17 13:37:27 2018
Return-Path: <linda.dunbar@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3060130DE5; Fri, 17 Aug 2018 13:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 ES7rRnGOEUSW; Fri, 17 Aug 2018 13:37:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 253AC129AB8; Fri, 17 Aug 2018 13:37:14 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C5801D36224A; Fri, 17 Aug 2018 21:37:08 +0100 (IST)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 17 Aug 2018 21:37:10 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.107]) by SJCEML701-CHM.china.huawei.com ([169.254.3.34]) with mapi id 14.03.0399.000; Fri, 17 Aug 2018 13:37:05 -0700
From: Linda Dunbar <linda.dunbar@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
CC: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Thread-Topic: Preventing BGP Route leak (Hijack) for Management Channel BGP session
Thread-Index: AdQzO4r0PzSwhpZvSCmMNMmO/EiBoACmr3EAAAjTVEAAEySuAAAIvzDg
Date: Fri, 17 Aug 2018 20:37:05 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B0DCC00@sjceml521-mbx.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net> <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com> <CAOj+MMH-LmcnB60qWftf1fPjLXpFt1MdVRJKw4CLg6qyBef9Zg@mail.gmail.com>
In-Reply-To: <CAOj+MMH-LmcnB60qWftf1fPjLXpFt1MdVRJKw4CLg6qyBef9Zg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.218.180.231]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B0DCC00sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Dkj7z9gmzeOPNIyiJ6LzQZENGBI>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 20:37:18 -0000

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DCC00sjceml521mbxchi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Um9iZXJ0LA0KDQpBY3R1YWxseSBJUHNlYyBQdWJsaWMga2V5IGJlaW5nIGhpamFja2VkIGRvZXNu
4oCZdCBwb3NlIGFueSBpc3N1ZSB0byBJUHNlYyBiZWNhdXNlIHRoZSBJUHNlYyBrZXkgaXMgZ2Vu
ZXJhdGVkIGJ5IFB1YmxpYyAmIFByaXZhdGUga2V5LCBsaWtlIElLRXYyIGlzIGV4Y2hhbmdlZCBv
dmVyIHB1YmxpYyBpbnRlcm5ldCwgd2hpbGUgYW55b25lIGNhbiBzZWUgaXQuDQoNClVzaW5nIEJH
UOKAmXMgUlIgdG8gZXhjaGFuZ2UgdGhlIFB1YmxpYyBrZXkgaXMgdG8gYXZvaWQgdGhlIFBlZXIg
QXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgb24gdGhlIFJlc291cmNlIENvbnN0cmFpbnQgQ1BF
cyAmIHZpcnR1YWwgQ1BFcy4NCk9mIGNhdXNlLCB3ZSBjYW4gdXNlIHNvbWUga2luZCBSZWdpc3Ry
YXRpb24gcHJvdG9jb2xzLCBzdWNoIGFzIE5IUlAsIHRvIGRvIHRoZSBqb2IuDQpTaW5jZSB0aG9z
ZSBDUEVzIGFscmVhZHkgc3VwcG9ydCBCR1AsIGxldmVyYWdpbmcgQkdQIHVwZGF0ZSBpcyBsZXNz
IHByb2Nlc3Npbmcgb24gdGhvc2UgcmVzb3VyY2UgY29uc3RyYWludCBDUEVzIHRoYW4gc3VwcG9y
dGluZyBhbm90aGVyIG5ldyBwcm90b2NvbC4NCg0KTGluZGENCg0KRnJvbTogUm9iZXJ0IFJhc3p1
ayBbbWFpbHRvOnJvYmVydEByYXN6dWsubmV0XQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMTcsIDIw
MTggNDoyMCBBTQ0KVG86IExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQpD
YzogRXJpYyBDIFJvc2VuIDxlcm9zZW5AanVuaXBlci5uZXQ+OyBpZHJAaWV0Zi5vcmc7IFJUR1dH
IDxydGd3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQcmV2ZW50aW5nIEJHUCBSb3V0ZSBsZWFr
IChIaWphY2spIGZvciBNYW5hZ2VtZW50IENoYW5uZWwgQkdQIHNlc3Npb24NCg0KSGkgTGluZGEs
DQoNCj4gcmVxdWlyaW5nIERhdGEgUGxhbiBCR1Agc2Vzc2lvbiB0byBiZSBjb21wbGV0ZWx5IHNl
cGFyYXRlIGZyb20gdGhlIE1hbmFnZW1lbnQgUGxhbmUgQkdQIHNlc3Npb24sIGlzIGl0IE9rYXk/
DQoNCkFzIEkgbWVudGlvbmVkIG9mZmxpbmUgdGhlcmUgaXMgbm8gZGlzdGluY3Rpb24gaW4gQkdQ
IGZvciBkYXRhIHBsYW5lIEJHUCBzZXNzaW9uIHZzIE1nbXQgUGxhbmUgQkdQIHNlc3Npb24uDQoN
CkJHUCBzZXNzaW9uIGlzIGEgQkdQIHNlc3Npb24gLSBwdXJlIFRDUCBzdHJlYW0gb2YgcGFja2V0
cyB3aGljaCBpcyBwcmV0dHkgdHJpdmlhbCB0byBpbnRlcmNlcHQsIGRlY29kZSwgaGlqYWNrLCBl
dGMgLi4uLg0KDQpNb3Jlb3ZlciBCR1AgbWVzc2FnZXMgYXJlIGRlc2lnbmVkIHRvIGJlIGZsb29k
ZWQgZXZlcnl3aGVyZSBpbiBhIHAybXAgZmFzaGlvbi4gRXZlbiBpZiB5b3UgYWRkICJOTy1BRFZF
UlRJU0UiIEJHUCBjb21tdW5pdHkgdG8gaXQgLSBjb21tdW5pdGllcyBjYW4gZ2V0IHN0cmlwcGVk
IGF1dG9tYXRpY2FsbHkgb24gYW55IEJHUCBzcGVha2VyLiBIZW5jZSB5b3UgY2xlYW4geW91ciBz
b2xlIHNhZmV0eSBwcm90ZWN0aW9uLg0KDQpUaGUgcXVlc3Rpb24gSSB3b3VsZCBsaWtlIHRvIHN0
YXRlIGFuZCB1bmRlcnN0b29kIC0gd2h5IGFyZSB5b3UgdHJ5aW5nIHNvIGhhcmQgdG8gdXNlIEJH
UCBmb3IgSVBTZWMgc2VjcmV0IGtleSBkaXN0cmlidXRpb24gPyBJcyB0aGlzIG9ubHkgZHVlIHRv
IHRoZSBmYWN0IHRoYXQgeW91IGhhdmUgaXQgdGhlcmUgPyBXYXNuJ3QgSUtFIGFuZCBub3cgaW1w
cm92ZWQgSUtFdjIgc3BlY2lmaWNhbGx5IGRlc2lnbmVkIHRvIGRvIGp1c3QgdGhhdCA/IEFueSBy
ZWFzb24geW91IGRvbid0IHdhbnQgdG8gdXNlIGl0ID8NCg0KVGh4LA0KUi4NCg0KDQoNCk9uIEZy
aSwgQXVnIDE3LCAyMDE4IGF0IDEyOjU5IEFNLCBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBo
dWF3ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+IHdyb3RlOg0KRXJpYywN
Cg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9uLg0KDQpJ
IG1lYW50IHRvIGFzayBhYm91dCB1c2luZyBCR1AgVVBEQVRFcyBvZiBhIHVuaXF1ZSBBRkkvU0FG
SSB0byBkaXN0cmlidXRlIHRoZSDigJxQdWJsaWMgS2V5c+KAnSBhbmQgaW5kaXZpZHVhbCDigJxO
b25jZeKAnSB0byBhbGwgdGhlIENQRXMuIEp1c3QgbGlrZSBJS0UgKHdoZXJlIHBlZXJzIGV4Y2hh
bmdlIHB1YmxpYyBrZXkgb3ZlciBpbnRlcm5ldCksIG5vdyB0aGUgUHVibGljIGtleXMgYXJlIGV4
Y2hhbmdlZCBiZXR3ZWVuIHBlZXJzIHZpYSBSUiAoQ29udHJvbGxlcikuIFdpdGggdGhpcyBhcHBy
b2FjaCwgdGhlIENQRXMgY2FuIG9mZmxvYWQgdGhlIFBlZXIgQXV0aGVudGljYXRpb24gam9iIHRv
IENvbnRyb2xsZXIuDQoNCklQc2Vj4oCZcyAgRGlmZmllLUhlbGxtYW4gYWxnb3JpdGhtIHVzZSDi
gJxQdWJsaWMgS2V54oCdIGFuZCBDUEXigJlzIFByaXZhdGUgS2V5IHRvIGNvbXB1dGUgdGhlIGFj
dHVhbCBTZWN1cml0eSBBc3NvY2lhdGlvbi4NCg0KSW4geW91ciBkcmFmdC1yb3Nlbi1iZXNzLXNl
Y3VyZS1sM3Zwbi0wMSwgeW91IGhhdmUgQkxBQ0sgQkdQIHNlc3Npb24gYW5kIFJFRCBCR1Agc2Vz
c2lvbiwgYW5kIGVtcGhhc2l6ZWQgb24gaG93IEJMQUNLIEJHUCBub3QgbGVha2luZyByb3V0ZXMg
dG8gUkVEIEJHUC4gSSB3YW50IHRvIGtub3cgaWYgd2UgY2FuIGRvIHRoZSBzYW1lIGZvciBNYW5h
Z2VtZW50IEJHUCBzZXNzaW9uLCBpLmUuIHJlcXVpcmluZyBEYXRhIFBsYW4gQkdQIHNlc3Npb24g
dG8gYmUgY29tcGxldGVseSBzZXBhcmF0ZSBmcm9tIHRoZSBNYW5hZ2VtZW50IFBsYW5lIEJHUCBz
ZXNzaW9uLCBpcyBpdCBPa2F5Pw0KDQpUaGFua3MsIExpbmRhIER1bmJhcg0KDQoNCg0KRnJvbTog
RXJpYyBDIFJvc2VuIFttYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0PG1haWx0bzplcm9zZW5AanVu
aXBlci5uZXQ+XQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxNiwgMjAxOCAyOjU5IFBNDQpUbzog
TGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFy
QGh1YXdlaS5jb20+Pjsgc2hhcmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+OyBp
ZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47IEplZmYgVGFudHN1cmEgPGplZmZ0YW50
LmlldGZAZ21haWwuY29tPG1haWx0bzpqZWZmdGFudC5pZXRmQGdtYWlsLmNvbT4+OyBSVEdXRyA8
cnRnd2dAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBQcmV2
ZW50aW5nIEJHUCBSb3V0ZSBsZWFrIChIaWphY2spIGZvciBNYW5hZ2VtZW50IENoYW5uZWwgQkdQ
IHNlc3Npb24NCg0KT24gOC8xMy8yMDE4IDM6MjYgUE0sIExpbmRhIER1bmJhciB3cm90ZToNCk9u
ZSBvZiB0aGUgY29tbWVudHMgdG8gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh
ZnQtZG0tbmV0MmNsb3VkLWdhcC1hbmFseXNpcy88aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJhZnQt
MkRkbS0yRG5ldDJjbG91ZC0yRGdhcC0yRGFuYWx5c2lzXyZkPUR3TUZBZyZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj0tRFhCODRlVTltNGNJbHEyT09jQ0pD
UVFBd0pYUVFzd3l1M0Ywa0cwVk5vJm09UlRvaDBVaFY3RjhjcDNxMnVkMUxtVTZHWnR5cFBUSmRi
b0w0ZGdwUnpyMCZzPTl4YktZajVmUDZKdjkzY29lNWctbGZ6cHAwTDBiSzBHeXJsQjkxUnkzU3cm
ZT0+IHRoZSBJbiBSVEd3ZyBzZXNzaW9uIG9mIElFVEYxMDIgaXMgdGhhdCB1c2luZyBCR1Agc2Vz
c2lvbiB0byBwYXNzIGNvbmZpZ3VyYXRpb24ga2V5cyBmb3IgSVBzZWMgY2FuIGJlIHJpc2t5IGV2
ZW4gaWYgdGhlIHBhdGggYmV0d2VlbiBSUiAmIG5vZGUgaXMgc2VjdXJlIChzYXkgdmlhIFRMUykg
ZHVlIHRvIEJHUCByb3V0ZSBsZWFrIChIaWphY2spLg0KQnV0IHRoZSBCR1Agc2Vzc2lvbiB0byBj
YXJyeSBJUHNlYyBjb25maWd1cmF0aW9ucyBpcyB2aWEgQkdQIG1hbmFnZW1lbnQgc2Vzc2lvbiwg
d2hpY2ggaXMgY29tcGxldGVseSBpc29sYXRlZCBmb3JtIHRoZSBkYXRhcGxhbmUgQkdQIHNlc3Np
b25zLi4NCg0KSSdtIG5vdCBzdXJlIEkgaGF2ZSB0aGUgd2hvbGUgY29udGV4dCwgYnV0IHRoZSBx
dWVzdGlvbiBzZWVtcyB0byBiZSB3aGV0aGVyIGl0IGNvdWxkIGV2ZXIgYmUgc2FmZSB0byB1c2Ug
QkdQIHRvIGRpc3RyaWJ1dGUgc2VjcmV0IGtleXMuDQoNClByZXN1bWFibHk6DQoNCi0gVGhlIGtl
eXMgd291bGQgYmUgY2FycmllZCBpbiBhbiBhdHRyaWJ1dGUgdGhhdCBjYW4gb25seSBiZSBhdHRh
Y2hlZCBieSBVUERBVEVzIG9mIGEgc3BlY2lmaWVkIEFGSS9TQUZJLCB3aGVyZSB0aGUgc3BlY2lm
aWVkIEFGSS9TQUZJIGlzIG9ubHkgdXNlZCB0byBjYXJyeSBtYW5hZ2VtZW50L2NvbmZpZ3VyYXRp
b24gaW5mb3JtYXRpb24uDQoNCi0gVVBEQVRFcyBvZiB0aGF0IEFGSS9TQUZJIHdvdWxkIG9ubHkg
YmUgc2VudCBvbiBCR1Agc2Vzc2lvbnMgdGhhdCBhcmUgYWRlcXVhdGVseSBzZWN1cmVkIHNvIGFz
IHRvIHByb3ZpZGUgcHJpdmFjeSwgaW50ZWdyaXR5IGFuZCBhdXRoZW50aWNhdGlvbi4NCg0KLSBU
aGUgVVBEQVRFcyB3b3VsZCBjYXJyeSB0aGUgTk9fQURWRVJUSVNFIGNvbW11bml0eSAodG8gbWFr
ZSBzdXJlIHRoZXkgYXJlIG5vdCBwcm9wYWdhdGVkIGZ1cnRoZXIpLg0KDQotIE5vbmUgb2YgdGhl
IEJHUCBzeXN0ZW1zIGludm9sdmVkIHdvdWxkIGFsbG93IGFueSBzb3J0IG9mICJCR1AgbW9uaXRv
cmluZyIgdGhhdCBtaWdodCBleHBvc2UgdGhlIHVuZW5jcnlwdGVkIGNvbnRlbnRzIG9mIHRoZSBV
UERBVEVzLg0KDQpJbiB0aGlzIHNjZW5hcmlvLCBJIGRvbid0IHRoaW5rIGl0IG1hdHRlcnMgd2hl
dGhlciB0aGUgc2VjdXJlIEJHUCBzZXNzaW9uIGFsc28gY2FycmllcyBvdGhlciBBRkkvU0FGSXMu
DQoNClRoZSBwcml2YWN5IHByb3BlcnRpZXMgb2YgdGhpcyBzY2VuYXJpbyBhcmUgcHJldHR5IGdv
b2QsIGluIHRoZW9yeSwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgcmVhbGx5IGdvb2QgZW5v
dWdoIGZvciBkaXN0cmlidXRpbmcgc2VjcmV0IGtleXMuDQoNCi0gT25jZSB5b3UncmUgdXNpbmcg
QkdQIHRvIGRpc3RyaWJ1dGUgaW5mb3JtYXRpb24sIGl0IGlzIGluZXZpdGFibGUgdGhhdCBzb21l
b25lIHdpbGwgZGVjaWRlIHRvIHJlbW92ZSB0aGUgIk5PX0FEVkVSVElTRSIgYW5kIGFsbG93IHRo
ZSBpbmZvcm1hdGlvbiB0byBiZSBwcm9wYWdhdGVkIHRocm91Z2ggaW50ZXJtZWRpYXRlIG5vZGVz
IChSUnMgb3IgQVNCUnMpIHRvIHRoZSBhY3R1YWwgdGFyZ2V0IG5vZGUuICBBZnRlciBhbGwsIG9u
ZSBvZiB0aGUgbWFpbiB2YWx1ZXMgb2YgdXNpbmcgQkdQIHRvIGRpc3RyaWJ1dGUgc3R1ZmYgaXMg
dGhhdCB5b3UgZ2V0IGEgYmlnIGRpc3RyaWJ1dGlvbiBzeXN0ZW0uICBFdmVuIGlmIGFsbCB0aGUg
aW50ZXJtZWRpYXRlIG5vZGVzIGFyZSB0cnVzdGVkIGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBC
R1Agc2Vzc2lvbnMgaGF2ZSBhZGVxdWF0ZSBwcml2YWN5L2ludGVncml0eS9hdXRoZW50aWNhdGlv
biwgeW91IHN0aWxsIHdvdWxkbid0IHdhbnQgdG8gZXhwb3NlIHRoZSBzZWNyZXQga2V5cyB0byB0
aG9zZSBub2Rlcy4gIFlvdSBtaWdodCB0cnVzdCB0aG9zZSBub2RlcyB0byBzZWUgYWxsIHRoZSBy
b3V0aW5nIGluZm9ybWF0aW9uLCBhbmQgZXZlbiB0byBzZWUgbW9zdCBvZiB0aGUgbWFuYWdlbWVu
dCBpbmZvcm1hdGlvbiwgYnV0IHlvdSBwcm9iYWJseSBkb24ndCB3YW50IHRoZW0gdG8gc2VlIGFs
bCB0aGUgc2VjcmV0IGtleXMuICBBbmQgeW91IHByb2JhYmx5IGRvbid0IHdhbnQgdGhlIHNlY3Jl
dCBrZXlzIHN0b3JlZCBpbiB0aGUgY2xlYXIgb24gdGhvc2UgaW50ZXJtZWRpYXRlIG5vZGVzLg0K
DQotIEkgd291bGQgd29ycnkgYWJvdXQgQkdQIG1vbml0b3JpbmcgcHJvY2VkdXJlcyBjcmVhdGlu
ZyBhIGJhY2tkb29yIHRocm91Z2ggd2hpY2ggdGhlIHNlY3JldCBrZXlzIHdvdWxkIGJlIGV4cG9z
ZWQuDQoNCi0gTm8gbWF0dGVyIGhvdyBjYXJlZnVsIHlvdSBhcmUsIHdoZW4geW91IHVzZSBCR1Ag
eW91IGNhbiBiZSBwcmV0dHkgc3VyZSB0aGF0IHlvdXIgVVBEQVRFcyB3aWxsIGVuZCB1cCBzb21l
d2hlcmUgdGhleSdyZSBub3Qgc3VwcG9zZWQgdG8gZ28uICBJdCdzIGp1c3QgdG9vIGVhc3kgdG8g
bWFrZSBtaXN0YWtlcy4NClNvIEkgZG9uJ3QgdGhpbmsgSSdkIHRyeSB0byBkbyBkeW5hbWljIGtl
eWluZyBieSBhdHRhY2hpbmcgdGhlIGFjdHVhbCBrZXlzIHRvIEJHUCBVUERBVEVzLiAgQXQgbW9z
dCBJJ2QgdXNlIEJHUCB0byBkaXN0cmlidXRlIHBhcmFtZXRlcnMgdGhhdCBjb3VsZCB0aGVuIGJl
IHVzZWQgYnkgc29tZXRoaW5nIGxpa2UgSUtFdjIgdG8gYWN0dWFsbHkgZmV0Y2ggdGhlIHNlY3Jl
dCBrZXlzLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KcnRnd2cgbWFpbGluZyBsaXN0DQpydGd3Z0BpZXRmLm9yZzxtYWlsdG86cnRnd2dAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnDQoNCg==

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DCC00sjceml521mbxchi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0
eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs
aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K
Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41
aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv
Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh
eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv
bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO
LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u
MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Um9iZXJ0LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BY3R1
YWxseSBJUHNlYyBQdWJsaWMga2V5IGJlaW5nIGhpamFja2VkIGRvZXNu4oCZdCBwb3NlIGFueSBp
c3N1ZSB0byBJUHNlYyBiZWNhdXNlIHRoZSBJUHNlYyBrZXkgaXMgZ2VuZXJhdGVkIGJ5IFB1Ymxp
YyAmYW1wOyBQcml2YXRlIGtleSwgbGlrZSBJS0V2MiBpcyBleGNoYW5nZWQgb3Zlcg0KIHB1Ymxp
YyBpbnRlcm5ldCwgd2hpbGUgYW55b25lIGNhbiBzZWUgaXQuIDxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VXNp
bmcgQkdQ4oCZcyBSUiB0byBleGNoYW5nZSB0aGUgUHVibGljIGtleSBpcyB0byBhdm9pZCB0aGUg
UGVlciBBdXRoZW50aWNhdGlvbiByZXF1aXJlbWVudCBvbiB0aGUgUmVzb3VyY2UgQ29uc3RyYWlu
dCBDUEVzICZhbXA7IHZpcnR1YWwgQ1BFcy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PZiBjYXVzZSwg
d2UgY2FuIHVzZSBzb21lIGtpbmQgUmVnaXN0cmF0aW9uIHByb3RvY29scywgc3VjaCBhcyBOSFJQ
LCB0byBkbyB0aGUgam9iLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNpbmNlIHRob3NlIENQRXMgYWxy
ZWFkeSBzdXBwb3J0IEJHUCwgbGV2ZXJhZ2luZyBCR1AgdXBkYXRlIGlzIGxlc3MgcHJvY2Vzc2lu
ZyBvbiB0aG9zZSByZXNvdXJjZSBjb25zdHJhaW50IENQRXMgdGhhbiBzdXBwb3J0aW5nIGFub3Ro
ZXIgbmV3IHByb3RvY29sLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5MaW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPiBSb2JlcnQgUmFzenVrIFttYWlsdG86cm9iZXJ0QHJhc3p1ay5u
ZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTggNDoyMCBBTTxi
cj4NCjxiPlRvOjwvYj4gTGluZGEgRHVuYmFyICZsdDtsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSZn
dDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgQyBSb3NlbiAmbHQ7ZXJvc2VuQGp1bmlwZXIubmV0Jmd0
OzsgaWRyQGlldGYub3JnOyBSVEdXRyAmbHQ7cnRnd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBQcmV2ZW50aW5nIEJHUCBSb3V0ZSBsZWFrIChIaWphY2spIGZvciBNYW5h
Z2VtZW50IENoYW5uZWwgQkdQIHNlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5IaSBMaW5kYSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO2JhY2tncm91bmQ6d2hpdGUiPiZn
dDsgcmVxdWlyaW5nIERhdGEgUGxhbiBCR1Agc2Vzc2lvbiB0byBiZSBjb21wbGV0ZWx5IHNlcGFy
YXRlIGZyb20gdGhlIE1hbmFnZW1lbnQgUGxhbmUgQkdQIHNlc3Npb24sIGlzIGl0IE9rYXk/PC9z
cGFuPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkFzIEkgbWVudGlvbmVkIG9mZmxpbmUgdGhlcmUgaXMgbm8gZGlzdGluY3Rpb24gaW4gQkdQ
IGZvciBkYXRhIHBsYW5lIEJHUCBzZXNzaW9uIHZzIE1nbXQgUGxhbmUgQkdQIHNlc3Npb24uJm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJHUCBzZXNzaW9uIGlzIGEgQkdQIHNlc3Npb24gLSBwdXJlIFRDUCBzdHJlYW0gb2YgcGFja2V0
cyB3aGljaCBpcyBwcmV0dHkgdHJpdmlhbCB0byBpbnRlcmNlcHQsIGRlY29kZSwgaGlqYWNrLCBl
dGMgLi4uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5Nb3Jlb3ZlciBCR1AgbWVzc2FnZXMgYXJlIGRlc2lnbmVkIHRvIGJlIGZsb29k
ZWQgZXZlcnl3aGVyZSBpbiBhIHAybXAgZmFzaGlvbi4gRXZlbiBpZiB5b3UgYWRkICZxdW90O05P
LUFEVkVSVElTRSZxdW90OyBCR1AgY29tbXVuaXR5IHRvIGl0IC0gY29tbXVuaXRpZXMgY2FuIGdl
dCBzdHJpcHBlZCBhdXRvbWF0aWNhbGx5IG9uIGFueSBCR1Agc3BlYWtlci4gSGVuY2UgeW91IGNs
ZWFuIHlvdXIgc29sZSBzYWZldHkgcHJvdGVjdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHF1ZXN0aW9uIEkgd291bGQg
bGlrZSB0byBzdGF0ZSBhbmQgdW5kZXJzdG9vZCAtIHdoeSBhcmUgeW91IHRyeWluZyBzbyBoYXJk
IHRvIHVzZSBCR1AgZm9yIElQU2VjIHNlY3JldCBrZXkgZGlzdHJpYnV0aW9uID8gSXMgdGhpcyBv
bmx5IGR1ZSB0byB0aGUgZmFjdCB0aGF0IHlvdSBoYXZlIGl0IHRoZXJlID8gV2Fzbid0IElLRSBh
bmQgbm93IGltcHJvdmVkIElLRXYyIHNwZWNpZmljYWxseSBkZXNpZ25lZA0KIHRvIGRvIGp1c3Qg
dGhhdCA/IEFueSByZWFzb24geW91IGRvbid0IHdhbnQgdG8gdXNlIGl0ID8mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGh4LDxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Ui48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZy
aSwgQXVnIDE3LCAyMDE4IGF0IDEyOjU5IEFNLCBMaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1h
aWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmxpbmRhLmR1bmJh
ckBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n
OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5FcmljLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+VGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9u
Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBtZWFu
dCB0byBhc2sgYWJvdXQgdXNpbmcgQkdQDQo8L3NwYW4+VVBEQVRFcyBvZiBhIHVuaXF1ZSBBRkkv
U0FGSSA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+DQp0byBkaXN0cmlidXRlIHRoZSDi
gJxQdWJsaWMgS2V5c+KAnSBhbmQgaW5kaXZpZHVhbCDigJxOb25jZeKAnSB0byBhbGwgdGhlIENQ
RXMuIEp1c3QgbGlrZSBJS0UgKHdoZXJlIHBlZXJzIGV4Y2hhbmdlIHB1YmxpYyBrZXkgb3ZlciBp
bnRlcm5ldCksIG5vdyB0aGUgUHVibGljIGtleXMgYXJlIGV4Y2hhbmdlZCBiZXR3ZWVuIHBlZXJz
IHZpYSBSUiAoQ29udHJvbGxlcikuIFdpdGggdGhpcyBhcHByb2FjaCwgdGhlIENQRXMgY2FuIG9m
ZmxvYWQgdGhlIFBlZXIgQXV0aGVudGljYXRpb24NCiBqb2IgdG8gQ29udHJvbGxlci4gPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SVBzZWPigJlzICZuYnNw
O0RpZmZpZS1IZWxsbWFuJm5ic3A7YWxnb3JpdGhtIHVzZSDigJxQdWJsaWMgS2V54oCdIGFuZCBD
UEXigJlzIFByaXZhdGUgS2V5IHRvIGNvbXB1dGUgdGhlIGFjdHVhbCBTZWN1cml0eQ0KIEFzc29j
aWF0aW9uLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J
biB5b3VyIGRyYWZ0LXJvc2VuLWJlc3Mtc2VjdXJlLWwzdnBuLTAxLCB5b3UgaGF2ZSBCTEFDSyBC
R1Agc2Vzc2lvbiBhbmQgUkVEIEJHUCBzZXNzaW9uLCBhbmQgZW1waGFzaXplZA0KIG9uIGhvdyBC
TEFDSyBCR1Agbm90IGxlYWtpbmcgcm91dGVzIHRvIFJFRCBCR1AuIEkgd2FudCB0byBrbm93IGlm
IHdlIGNhbiBkbyB0aGUgc2FtZSBmb3IgTWFuYWdlbWVudCBCR1Agc2Vzc2lvbiwgaS5lLiByZXF1
aXJpbmcgRGF0YSBQbGFuIEJHUCBzZXNzaW9uIHRvIGJlIGNvbXBsZXRlbHkgc2VwYXJhdGUgZnJv
bSB0aGUgTWFuYWdlbWVudCBQbGFuZSBCR1Agc2Vzc2lvbiwgaXMgaXQgT2theT8NCjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgTGluZGEgRHVu
YmFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJt
Xy04Nzg3MzEzMTU4Njg5MTAwODAwX19NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIEMgUm9zZW4g
W21haWx0bzo8YSBocmVmPSJtYWlsdG86ZXJvc2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFu
ayI+ZXJvc2VuQGp1bmlwZXIubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg
QXVndXN0IDE2LCAyMDE4IDI6NTkgUE08YnI+DQo8Yj5Ubzo8L2I+IExpbmRhIER1bmJhciAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+
bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzaGFyZXNA
bmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNAbmR6aC5jb208L2E+OyA8YSBocmVmPSJt
YWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppZHJAaWV0Zi5vcmc8L2E+OyBK
ZWZmIFRhbnRzdXJhICZsdDs8YSBocmVmPSJtYWlsdG86amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20i
IHRhcmdldD0iX2JsYW5rIj5qZWZmdGFudC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7OyBSVEdXRyAm
bHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Z3dnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cnRnd2dA
aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUHJldmVudGluZyBCR1Ag
Um91dGUgbGVhayAoSGlqYWNrKSBmb3IgTWFuYWdlbWVudCBDaGFubmVsIEJHUCBzZXNzaW9uPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDgvMTMvMjAxOCAz
OjI2IFBNLCBMaW5kYSBEdW5iYXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+T25lIG9mIHRoZSBjb21tZW50cyB0bw0KPGEgaHJlZj0iaHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRm
Lm9yZ19kb2NfZHJhZnQtMkRkbS0yRG5ldDJjbG91ZC0yRGdhcC0yRGFuYWx5c2lzXyZhbXA7ZD1E
d01GQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZh
bXA7cj0tRFhCODRlVTltNGNJbHEyT09jQ0pDUVFBd0pYUVFzd3l1M0Ywa0cwVk5vJmFtcDttPVJU
b2gwVWhWN0Y4Y3AzcTJ1ZDFMbVU2R1p0eXBQVEpkYm9MNGRncFJ6cjAmYW1wO3M9OXhiS1lqNWZQ
Nkp2OTNjb2U1Zy1sZnpwcDBMMGJLMEd5cmxCOTFSeTNTdyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5r
Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRtLW5ldDJjbG91ZC1n
YXAtYW5hbHlzaXMvPC9hPiB0aGUgSW4gUlRHd2cgc2Vzc2lvbiBvZiBJRVRGMTAyIGlzIHRoYXQg
dXNpbmcgQkdQIHNlc3Npb24gdG8gcGFzcyBjb25maWd1cmF0aW9uIGtleXMgZm9yIElQc2VjIGNh
biBiZSByaXNreSBldmVuIGlmIHRoZSBwYXRoIGJldHdlZW4gUlIgJmFtcDsgbm9kZSBpcyBzZWN1
cmUgKHNheSB2aWEgVExTKSBkdWUgdG8gQkdQIHJvdXRlIGxlYWsNCiAoSGlqYWNrKS4gPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1dCB0aGUgQkdQIHNlc3Npb24gdG8g
Y2FycnkgSVBzZWMgY29uZmlndXJhdGlvbnMgaXMgdmlhIEJHUCBtYW5hZ2VtZW50IHNlc3Npb24s
IHdoaWNoIGlzIGNvbXBsZXRlbHkgaXNvbGF0ZWQgZm9ybSB0aGUgZGF0YXBsYW5lIEJHUCBzZXNz
aW9ucy4uDQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGJyPg0KSSdtIG5vdCBzdXJlIEkgaGF2ZSB0aGUgd2hvbGUgY29udGV4dCwgYnV0IHRoZSBxdWVz
dGlvbiBzZWVtcyB0byBiZSB3aGV0aGVyIGl0IGNvdWxkIGV2ZXIgYmUgc2FmZSB0byB1c2UgQkdQ
IHRvIGRpc3RyaWJ1dGUgc2VjcmV0IGtleXMuPGJyPg0KPGJyPg0KUHJlc3VtYWJseTo8YnI+DQo8
YnI+DQotIFRoZSBrZXlzIHdvdWxkIGJlIGNhcnJpZWQgaW4gYW4gYXR0cmlidXRlIHRoYXQgY2Fu
IG9ubHkgYmUgYXR0YWNoZWQgYnkgVVBEQVRFcyBvZiBhIHNwZWNpZmllZCBBRkkvU0FGSSwgd2hl
cmUgdGhlIHNwZWNpZmllZCBBRkkvU0FGSSBpcyBvbmx5IHVzZWQgdG8gY2FycnkgbWFuYWdlbWVu
dC9jb25maWd1cmF0aW9uIGluZm9ybWF0aW9uLjxicj4NCjxicj4NCi0gVVBEQVRFcyBvZiB0aGF0
IEFGSS9TQUZJIHdvdWxkIG9ubHkgYmUgc2VudCBvbiBCR1Agc2Vzc2lvbnMgdGhhdCBhcmUgYWRl
cXVhdGVseSBzZWN1cmVkIHNvIGFzIHRvIHByb3ZpZGUgcHJpdmFjeSwgaW50ZWdyaXR5IGFuZCBh
dXRoZW50aWNhdGlvbi48YnI+DQo8YnI+DQotIFRoZSBVUERBVEVzIHdvdWxkIGNhcnJ5IHRoZSBO
T19BRFZFUlRJU0UgY29tbXVuaXR5ICh0byBtYWtlIHN1cmUgdGhleSBhcmUgbm90IHByb3BhZ2F0
ZWQgZnVydGhlcikuPGJyPg0KPGJyPg0KLSBOb25lIG9mIHRoZSBCR1Agc3lzdGVtcyBpbnZvbHZl
ZCB3b3VsZCBhbGxvdyBhbnkgc29ydCBvZiAmcXVvdDtCR1AgbW9uaXRvcmluZyZxdW90OyB0aGF0
IG1pZ2h0IGV4cG9zZSB0aGUgdW5lbmNyeXB0ZWQgY29udGVudHMgb2YgdGhlIFVQREFURXMuPGJy
Pg0KPGJyPg0KSW4gdGhpcyBzY2VuYXJpbywgSSBkb24ndCB0aGluayBpdCBtYXR0ZXJzIHdoZXRo
ZXIgdGhlIHNlY3VyZSBCR1Agc2Vzc2lvbiBhbHNvIGNhcnJpZXMgb3RoZXIgQUZJL1NBRklzLjxi
cj4NCjxicj4NClRoZSBwcml2YWN5IHByb3BlcnRpZXMgb2YgdGhpcyBzY2VuYXJpbyBhcmUgcHJl
dHR5IGdvb2QsIGluIHRoZW9yeSwgYnV0IEkgZG9uJ3QgdGhpbmsgdGhleSBhcmUgcmVhbGx5IGdv
b2QgZW5vdWdoIGZvciBkaXN0cmlidXRpbmcgc2VjcmV0IGtleXMuPGJyPg0KPGJyPg0KLSBPbmNl
IHlvdSdyZSB1c2luZyBCR1AgdG8gZGlzdHJpYnV0ZSBpbmZvcm1hdGlvbiwgaXQgaXMgaW5ldml0
YWJsZSB0aGF0IHNvbWVvbmUgd2lsbCBkZWNpZGUgdG8gcmVtb3ZlIHRoZSAmcXVvdDtOT19BRFZF
UlRJU0UmcXVvdDsgYW5kIGFsbG93IHRoZSBpbmZvcm1hdGlvbiB0byBiZSBwcm9wYWdhdGVkIHRo
cm91Z2ggaW50ZXJtZWRpYXRlIG5vZGVzIChSUnMgb3IgQVNCUnMpIHRvIHRoZSBhY3R1YWwgdGFy
Z2V0IG5vZGUuJm5ic3A7IEFmdGVyIGFsbCwgb25lIG9mIHRoZQ0KIG1haW4gdmFsdWVzIG9mIHVz
aW5nIEJHUCB0byBkaXN0cmlidXRlIHN0dWZmIGlzIHRoYXQgeW91IGdldCBhIGJpZyBkaXN0cmli
dXRpb24gc3lzdGVtLiZuYnNwOyBFdmVuIGlmIGFsbCB0aGUgaW50ZXJtZWRpYXRlIG5vZGVzIGFy
ZSB0cnVzdGVkIGFuZCBhbGwgdGhlIGludGVybWVkaWF0ZSBCR1Agc2Vzc2lvbnMgaGF2ZSBhZGVx
dWF0ZSBwcml2YWN5L2ludGVncml0eS9hdXRoZW50aWNhdGlvbiwgeW91IHN0aWxsIHdvdWxkbid0
IHdhbnQgdG8gZXhwb3NlDQogdGhlIHNlY3JldCBrZXlzIHRvIHRob3NlIG5vZGVzLiZuYnNwOyBZ
b3UgbWlnaHQgdHJ1c3QgdGhvc2Ugbm9kZXMgdG8gc2VlIGFsbCB0aGUgcm91dGluZyBpbmZvcm1h
dGlvbiwgYW5kIGV2ZW4gdG8gc2VlIG1vc3Qgb2YgdGhlIG1hbmFnZW1lbnQgaW5mb3JtYXRpb24s
IGJ1dCB5b3UgcHJvYmFibHkgZG9uJ3Qgd2FudCB0aGVtIHRvIHNlZSBhbGwgdGhlIHNlY3JldCBr
ZXlzLiZuYnNwOyBBbmQgeW91IHByb2JhYmx5IGRvbid0IHdhbnQgdGhlIHNlY3JldCBrZXlzIHN0
b3JlZA0KIGluIHRoZSBjbGVhciBvbiB0aG9zZSBpbnRlcm1lZGlhdGUgbm9kZXMuPGJyPg0KPGJy
Pg0KLSBJIHdvdWxkIHdvcnJ5IGFib3V0IEJHUCBtb25pdG9yaW5nIHByb2NlZHVyZXMgY3JlYXRp
bmcgYSBiYWNrZG9vciB0aHJvdWdoIHdoaWNoIHRoZSBzZWNyZXQga2V5cyB3b3VsZCBiZSBleHBv
c2VkLiZuYnNwOw0KPGJyPg0KPGJyPg0KLSBObyBtYXR0ZXIgaG93IGNhcmVmdWwgeW91IGFyZSwg
d2hlbiB5b3UgdXNlIEJHUCB5b3UgY2FuIGJlIHByZXR0eSBzdXJlIHRoYXQgeW91ciBVUERBVEVz
IHdpbGwgZW5kIHVwIHNvbWV3aGVyZSB0aGV5J3JlIG5vdCBzdXBwb3NlZCB0byBnby4mbmJzcDsg
SXQncyBqdXN0IHRvbyBlYXN5IHRvIG1ha2UgbWlzdGFrZXMuJm5ic3A7DQo8YnI+DQpTbyBJIGRv
bid0IHRoaW5rIEknZCB0cnkgdG8gZG8gZHluYW1pYyBrZXlpbmcgYnkgYXR0YWNoaW5nIHRoZSBh
Y3R1YWwga2V5cyB0byBCR1AgVVBEQVRFcy4mbmJzcDsgQXQgbW9zdCBJJ2QgdXNlIEJHUCB0byBk
aXN0cmlidXRlIHBhcmFtZXRlcnMgdGhhdCBjb3VsZCB0aGVuIGJlIHVzZWQgYnkgc29tZXRoaW5n
IGxpa2UgSUtFdjIgdG8gYWN0dWFsbHkgZmV0Y2ggdGhlIHNlY3JldCBrZXlzLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpydGd3ZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
cnRnd2dAaWV0Zi5vcmciPnJ0Z3dnQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnd2ciIHRhcmdldD0iX2JsYW5rIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Z3dnPC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4A95BA014132FF49AE685FAB4B9F17F66B0DCC00sjceml521mbxchi_--


From nobody Fri Aug 17 14:51:52 2018
Return-Path: <jefftant.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF48130E07; Fri, 17 Aug 2018 14:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.008
X-Spam-Level: 
X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 VZ3KIy_n7HBy; Fri, 17 Aug 2018 14:51:39 -0700 (PDT)
Received: from mail-pl0-x242.google.com (mail-pl0-x242.google.com [IPv6:2607:f8b0:400e:c01::242]) (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 61D86130FCA; Fri, 17 Aug 2018 14:51:39 -0700 (PDT)
Received: by mail-pl0-x242.google.com with SMTP id d5-v6so4284896pll.4; Fri, 17 Aug 2018 14:51:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=bSRR+vJ8kdJDGdjAk7lZDlb9Td6U4YE5FLM5KnB/KBM=; b=IZaXebFsb2Kyot4VXeAbLiA3E5UBsRVvhRqs3ZjoKZPIGYyWKKJ7fkSPpmlyY4rDuI Pd5QiTQAtd2NkwxEfiyWKrZX+z6TjE+rM3cqhtYrG1y/jv2GdF2PUJBHZ2hOdOgQSvsb l0ltIzqBJK8RKExGz25U56GxZDpJxkY+34mQWC7hD3eOX2cKy8uxZT9VHdPsPBlbjlDX 6uwNUtXcWPrRJC7/sbZzkxhFaZS1ixDBqGhitUQqhv11HRgWuEAQXm/JU00wnNeWEbrQ iaiYjvmxeJX4B4yYZYN26rH6izSwcuCSMLaRRJil8CjmDMBTPtWkNX/jcoDOGWSvkyaM 6hoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=bSRR+vJ8kdJDGdjAk7lZDlb9Td6U4YE5FLM5KnB/KBM=; b=nwnrIp/wLDSmTee9owLADpXOdN4kg0cgae3t+i8M+zX5I3A4+quIF2BqP/cdUsV/vy fMuBncf+RtG0KfD0JcyGn2aD9299ey7PmasvIKkIjgrC2xoUQYc9bg4eLpbT/Kjhz9v4 prDcPHWCztjcnLk3bLhtoilsDBIJMM69wxCWN45yEnDocMZYHXcnRA5I1sMlXIpgILyV 7CLgjTHln6NpnrlTrprkrED/8TFNquJ00Mc2+P4PxMsYQo/WoKg+A6Vf82gHtrEF/Aqc JZ+njqRnqvY15JCK8XHWyZVdqwXRJlgkrcxINT0KmxmcteFJF8eKCosGAlYqzuGiMpvU UHRA==
X-Gm-Message-State: AOUpUlGthGsR7tVcJOvl0Xf4CuvsmHQsZ6jhc2InE7O7kFOkTCvyzzCp A54DtiQLZsW3F9Ql+k4Vmjo=
X-Google-Smtp-Source: AA+uWPydJryffuY5T0/2lWZ92DDxcYSSdW2waDWLMiUU8G25owy+C+MiA48RKKHLs1902a8TckaXOg==
X-Received: by 2002:a17:902:227:: with SMTP id 36-v6mr35818688plc.103.1534542698946;  Fri, 17 Aug 2018 14:51:38 -0700 (PDT)
Received: from [192.168.1.17] ([2601:647:5801:7388:6c90:cd33:9b26:703e]) by smtp.gmail.com with ESMTPSA id l84-v6sm6103664pfg.3.2018.08.17.14.51.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 14:51:38 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.f.0.180709
Date: Fri, 17 Aug 2018 14:51:37 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Message-ID: <571B830A-5265-49CA-8646-1F7B17461F55@gmail.com>
Thread-Topic: Preventing BGP Route leak (Hijack) for Management Channel BGP session
References: <4A95BA014132FF49AE685FAB4B9F17F66B0DAE87@sjceml521-mbx.china.huawei.com> <d6d522ea-f555-9344-0dee-732bb9983ef9@juniper.net> <4A95BA014132FF49AE685FAB4B9F17F66B0DC48F@sjceml521-mbx.china.huawei.com> <CAOj+MMH-LmcnB60qWftf1fPjLXpFt1MdVRJKw4CLg6qyBef9Zg@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B0DCC00@sjceml521-mbx.china.huawei.com>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B0DCC00@sjceml521-mbx.china.huawei.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3617362297_1312349409"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Wwxvjh7hM2dJc2agLo7kZqpxXSc>
Subject: Re: [Idr] Preventing BGP Route leak (Hijack) for Management Channel BGP session
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Aug 2018 21:51:43 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3617362297_1312349409
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

/as working group contributor

=20

Linda,

=20

I disagree with =E2=80=9Calready support BGP=E2=80=9D point as the right argument to us=
e BGP for key distribution.

In most cases, after booting up=C2=A0 1st time, CPE would =E2=80=9Ccall back home=E2=80=9D =
to activate and obtain right SW, config, etc

BGP session(s) would be configured/activated later

=20

Cheers,

Jeff

=20

From: rtgwg <rtgwg-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunba=
r@huawei.com>
Date: Friday, August 17, 2018 at 13:37
To: Robert Raszuk <robert@raszuk.net>
Cc: "idr@ietf.org" <idr@ietf.org>, RTGWG <rtgwg@ietf.org>
Subject: RE: Preventing BGP Route leak (Hijack) for Management Channel BGP =
session

=20

Robert,=20

=20

Actually IPsec Public key being hijacked doesn=E2=80=99t pose any issue to IPsec =
because the IPsec key is generated by Public & Private key, like IKEv2 is ex=
changed over public internet, while anyone can see it.=20

=20

Using BGP=E2=80=99s RR to exchange the Public key is to avoid the Peer Authentica=
tion requirement on the Resource Constraint CPEs & virtual CPEs.=20

Of cause, we can use some kind Registration protocols, such as NHRP, to do =
the job.=20

Since those CPEs already support BGP, leveraging BGP update is less process=
ing on those resource constraint CPEs than supporting another new protocol.=20

=20

Linda

=20

From: Robert Raszuk [mailto:robert@raszuk.net]=20
Sent: Friday, August 17, 2018 4:20 AM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: Eric C Rosen <erosen@juniper.net>; idr@ietf.org; RTGWG <rtgwg@ietf.org>
Subject: Re: Preventing BGP Route leak (Hijack) for Management Channel BGP =
session

=20

Hi Linda,

=20

> requiring Data Plan BGP session to be completely separate from the Manage=
ment Plane BGP session, is it Okay?=20

=20

As I mentioned offline there is no distinction in BGP for data plane BGP se=
ssion vs Mgmt Plane BGP session.=20

=20

BGP session is a BGP session - pure TCP stream of packets which is pretty t=
rivial to intercept, decode, hijack, etc ....=20

=20

Moreover BGP messages are designed to be flooded everywhere in a p2mp fashi=
on. Even if you add "NO-ADVERTISE" BGP community to it - communities can get=
 stripped automatically on any BGP speaker. Hence you clean your sole safety=
 protection.=20

=20

The question I would like to state and understood - why are you trying so h=
ard to use BGP for IPSec secret key distribution ? Is this only due to the f=
act that you have it there ? Wasn't IKE and now improved IKEv2 specifically =
designed to do just that ? Any reason you don't want to use it ?=20

=20

Thx,

R.

=20

=20

=20

On Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar <linda.dunbar@huawei.com> wr=
ote:

Eric,=20

=20

Thank you very much for the detailed explanation.=20

=20

I meant to ask about using BGP UPDATEs of a unique AFI/SAFI to distribute t=
he =E2=80=9CPublic Keys=E2=80=9D and individual =E2=80=9CNonce=E2=80=9D to all the CPEs. Just like I=
KE (where peers exchange public key over internet), now the Public keys are =
exchanged between peers via RR (Controller). With this approach, the CPEs ca=
n offload the Peer Authentication job to Controller.=20

=20

IPsec=E2=80=99s  Diffie-Hellman algorithm use =E2=80=9CPublic Key=E2=80=9D and CPE=E2=80=99s Privat=
e Key to compute the actual Security Association.=20

=20

In your draft-rosen-bess-secure-l3vpn-01, you have BLACK BGP session and RE=
D BGP session, and emphasized on how BLACK BGP not leaking routes to RED BGP=
. I want to know if we can do the same for Management BGP session, i.e. requ=
iring Data Plan BGP session to be completely separate from the Management Pl=
ane BGP session, is it Okay?=20

=20

Thanks, Linda Dunbar

=20

=20

=20

From: Eric C Rosen [mailto:erosen@juniper.net]=20
Sent: Thursday, August 16, 2018 2:59 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; shares@ndzh.com; idr@ietf.org; =
Jeff Tantsura <jefftant.ietf@gmail.com>; RTGWG <rtgwg@ietf.org>
Subject: Re: Preventing BGP Route leak (Hijack) for Management Channel BGP =
session

=20

On 8/13/2018 3:26 PM, Linda Dunbar wrote:

One of the comments to https://datatracker.ietf.org/doc/draft-dm-net2cloud-=
gap-analysis/ the In RTGwg session of IETF102 is that using BGP session to p=
ass configuration keys for IPsec can be risky even if the path between RR & =
node is secure (say via TLS) due to BGP route leak (Hijack).=20

But the BGP session to carry IPsec configurations is via BGP management ses=
sion, which is completely isolated form the dataplane BGP sessions..=20


I'm not sure I have the whole context, but the question seems to be whether=
 it could ever be safe to use BGP to distribute secret keys.

Presumably:

- The keys would be carried in an attribute that can only be attached by UP=
DATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used to =
carry management/configuration information.

- UPDATEs of that AFI/SAFI would only be sent on BGP sessions that are adeq=
uately secured so as to provide privacy, integrity and authentication.

- The UPDATEs would carry the NO_ADVERTISE community (to make sure they are=
 not propagated further).

- None of the BGP systems involved would allow any sort of "BGP monitoring"=
 that might expose the unencrypted contents of the UPDATEs.

In this scenario, I don't think it matters whether the secure BGP session a=
lso carries other AFI/SAFIs.

The privacy properties of this scenario are pretty good, in theory, but I d=
on't think they are really good enough for distributing secret keys.

- Once you're using BGP to distribute information, it is inevitable that so=
meone will decide to remove the "NO_ADVERTISE" and allow the information to =
be propagated through intermediate nodes (RRs or ASBRs) to the actual target=
 node.  After all, one of the main values of using BGP to distribute stuff i=
s that you get a big distribution system.  Even if all the intermediate node=
s are trusted and all the intermediate BGP sessions have adequate privacy/in=
tegrity/authentication, you still wouldn't want to expose the secret keys to=
 those nodes.  You might trust those nodes to see all the routing informatio=
n, and even to see most of the management information, but you probably don'=
t want them to see all the secret keys.  And you probably don't want the sec=
ret keys stored in the clear on those intermediate nodes.

- I would worry about BGP monitoring procedures creating a backdoor through=
 which the secret keys would be exposed. =20

- No matter how careful you are, when you use BGP you can be pretty sure th=
at your UPDATEs will end up somewhere they're not supposed to go.  It's just=
 too easy to make mistakes. =20
So I don't think I'd try to do dynamic keying by attaching the actual keys =
to BGP UPDATEs.  At most I'd use BGP to distribute parameters that could the=
n be used by something like IKEv2 to actually fetch the secret keys.


_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

=20

_______________________________________________ rtgwg mailing list rtgwg@ie=
tf.org https://www.ietf.org/mailman/listinfo/rtgwg=20


--B_3617362297_1312349409
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:schema=
s-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/office/20=
04/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equiv=3DC=
ontent-Type content=3D"text/html; charset=3Dutf-8"><meta name=3DGenerator content=3D=
"Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style></head><body lang=3DEN-US link=3Dblue vlink=3Dpurple><div class=3DWordSe=
ction1><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri=
",sans-serif'>/as working group contributor<o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p=
>&nbsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fon=
t-family:"Calibri",sans-serif'>Linda,<o:p></o:p></span></p><p class=3DMsoNorma=
l><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p>&nbsp=
;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami=
ly:"Calibri",sans-serif'>I disagree with =E2=80=9Calready support BGP=E2=80=9D point as =
the right argument to use BGP for key distribution.<o:p></o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-ser=
if'>In most cases, after booting up=C2=A0 1<sup>st</sup> time, CPE would =E2=80=9Ccall=
 back home=E2=80=9D to activate and obtain right SW, config, etc<o:p></o:p></span>=
</p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",s=
ans-serif'>BGP session(s) would be configured/activated later<o:p></o:p></sp=
an></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri=
",sans-serif'><o:p>&nbsp;</o:p></span></p><div><p class=3DMsoNormal><span styl=
e=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>Cheers,<o:=
p></o:p></span></p></div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fo=
nt-family:"Calibri",sans-serif;color:black'>Jeff</span><span style=3D'font-siz=
e:11.0pt;font-family:"Calibri",sans-serif'><o:p></o:p></span></p><p class=3DMs=
oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><o:p=
>&nbsp;</o:p></span></p><div style=3D'border:none;border-top:solid #B5C4DF 1.0=
pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'color:black=
'>From: </span></b><span style=3D'color:black'>rtgwg &lt;rtgwg-bounces@ietf.or=
g&gt; on behalf of Linda Dunbar &lt;linda.dunbar@huawei.com&gt;<br><b>Date: =
</b>Friday, August 17, 2018 at 13:37<br><b>To: </b>Robert Raszuk &lt;robert@=
raszuk.net&gt;<br><b>Cc: </b>&quot;idr@ietf.org&quot; &lt;idr@ietf.org&gt;, =
RTGWG &lt;rtgwg@ietf.org&gt;<br><b>Subject: </b>RE: Preventing BGP Route lea=
k (Hijack) for Management Channel BGP session<o:p></o:p></span></p></div><di=
v><p class=3DMsoNormal><span style=3D'font-size:11.0pt'><o:p>&nbsp;</o:p></span>=
</p></div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cali=
bri",sans-serif;color:#1F497D'>Robert, </span><o:p></o:p></p><p class=3DMsoNor=
mal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F=
497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:=
11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Actually IPsec Public=
 key being hijacked doesn=E2=80=99t pose any issue to IPsec because the IPsec key =
is generated by Public &amp; Private key, like IKEv2 is exchanged over publi=
c internet, while anyone can see it. </span><o:p></o:p></p><p class=3DMsoNorma=
l><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F49=
7D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:11=
.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Using BGP=E2=80=99s RR to exc=
hange the Public key is to avoid the Peer Authentication requirement on the =
Resource Constraint CPEs &amp; virtual CPEs. </span><o:p></o:p></p><p class=3D=
MsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;col=
or:#1F497D'>Of cause, we can use some kind Registration protocols, such as N=
HRP, to do the job. </span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'fo=
nt-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Since those C=
PEs already support BGP, leveraging BGP update is less processing on those r=
esource constraint CPEs than supporting another new protocol. </span><o:p></=
o:p></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibr=
i",sans-serif;color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal>=
<span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D=
'>Linda</span><o:p></o:p></p><p class=3DMsoNormal><span style=3D'font-size:11.0p=
t;font-family:"Calibri",sans-serif;color:#1F497D'>&nbsp;</span><o:p></o:p></=
p><p class=3DMsoNormal><b><span style=3D'font-size:11.0pt;font-family:"Calibri",=
sans-serif'>From:</span></b><span style=3D'font-size:11.0pt;font-family:"Calib=
ri",sans-serif'> Robert Raszuk [mailto:robert@raszuk.net] <br><b>Sent:</b> F=
riday, August 17, 2018 4:20 AM<br><b>To:</b> Linda Dunbar &lt;linda.dunbar@h=
uawei.com&gt;<br><b>Cc:</b> Eric C Rosen &lt;erosen@juniper.net&gt;; idr@iet=
f.org; RTGWG &lt;rtgwg@ietf.org&gt;<br><b>Subject:</b> Re: Preventing BGP Ro=
ute leak (Hijack) for Management Channel BGP session</span><o:p></o:p></p><p=
 class=3DMsoNormal>&nbsp;<o:p></o:p></p><div><p class=3DMsoNormal>Hi Linda,<o:p>=
</o:p></p><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><p class=3DM=
soNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;colo=
r:#1F497D;background:white'>&gt; requiring Data Plan BGP session to be compl=
etely separate from the Management Plane BGP session, is it Okay?</span> <o:=
p></o:p></p></div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><p=
 class=3DMsoNormal>As I mentioned offline there is no distinction in BGP for d=
ata plane BGP session vs Mgmt Plane BGP session.&nbsp;<o:p></o:p></p></div><=
div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal>BG=
P session is a BGP session - pure TCP stream of packets which is pretty triv=
ial to intercept, decode, hijack, etc ....&nbsp;<o:p></o:p></p></div><div><p=
 class=3DMsoNormal>&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal>Moreover=
 BGP messages are designed to be flooded everywhere in a p2mp fashion. Even =
if you add &quot;NO-ADVERTISE&quot; BGP community to it - communities can ge=
t stripped automatically on any BGP speaker. Hence you clean your sole safet=
y protection.&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal>&nbsp;<o:p><=
/o:p></p></div><div><p class=3DMsoNormal>The question I would like to state an=
d understood - why are you trying so hard to use BGP for IPSec secret key di=
stribution ? Is this only due to the fact that you have it there ? Wasn't IK=
E and now improved IKEv2 specifically designed to do just that ? Any reason =
you don't want to use it ?&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal=
>&nbsp;<o:p></o:p></p></div><div><p class=3DMsoNormal>Thx,<o:p></o:p></p></div=
><div><p class=3DMsoNormal>R.<o:p></o:p></p></div><div><p class=3DMsoNormal>&nbs=
p;<o:p></o:p></p></div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p></div></=
div><div><p class=3DMsoNormal>&nbsp;<o:p></o:p></p><div><p class=3DMsoNormal>On =
Fri, Aug 17, 2018 at 12:59 AM, Linda Dunbar &lt;<a href=3D"mailto:linda.dunbar=
@huawei.com" target=3D"_blank">linda.dunbar@huawei.com</a>&gt; wrote:<o:p></o:=
p></p><blockquote style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding=
:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margi=
n-bottom:5.0pt'><div><div><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;=
mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calib=
ri",sans-serif;color:#1F497D'>Eric, </span><o:p></o:p></p><p class=3DMsoNormal=
 style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'fon=
t-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>&nbsp;</span><=
o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-b=
ottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-ser=
if;color:#1F497D'>Thank you very much for the detailed explanation. </span><=
o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-b=
ottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-ser=
if;color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-=
margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0p=
t;font-family:"Calibri",sans-serif;color:#1F497D'>I meant to ask about using=
 BGP </span>UPDATEs of a unique AFI/SAFI <span style=3D'font-size:11.0pt;font-=
family:"Calibri",sans-serif;color:#1F497D'>to distribute the =E2=80=9CPublic Keys=E2=
=80=9D and individual =E2=80=9CNonce=E2=80=9D to all the CPEs. Just like IKE (where peers ex=
change public key over internet), now the Public keys are exchanged between =
peers via RR (Controller). With this approach, the CPEs can offload the Peer=
 Authentication job to Controller. </span><o:p></o:p></p><p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font=
-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>&nbsp;</span><o=
:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bo=
ttom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-seri=
f;color:#1F497D'>IPsec=E2=80=99s &nbsp;Diffie-Hellman&nbsp;algorithm use =E2=80=9CPublic=
 Key=E2=80=9D and CPE=E2=80=99s Private Key to compute the actual Security Association. =
</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-=
margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:"Calibri",=
sans-serif;color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DMsoNormal sty=
le=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-si=
ze:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>In your draft-rose=
n-bess-secure-l3vpn-01, you have BLACK BGP session and RED BGP session, and =
emphasized on how BLACK BGP not leaking routes to RED BGP. I want to know if=
 we can do the same for Management BGP session, i.e. requiring Data Plan BGP=
 session to be completely separate from the Management Plane BGP session, is=
 it Okay? </span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt=
:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-family:=
"Calibri",sans-serif;color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DMso=
Normal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span styl=
e=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks, =
Linda Dunbar</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-a=
lt:auto;mso-margin-bottom-alt:auto'><span style=3D'font-size:11.0pt;font-famil=
y:"Calibri",sans-serif;color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=3DM=
soNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span st=
yle=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>&nbsp;=
</span><o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-=
margin-bottom-alt:auto'><a name=3D"m_-8787313158689100800__MailEndCompose"><sp=
an style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>&=
nbsp;</span></a><o:p></o:p></p><div><div style=3D'border:none;border-top:solid=
 #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal style=3D'mso-marg=
in-top-alt:auto;mso-margin-bottom-alt:auto'><b><span style=3D'font-size:11.0pt=
;font-family:"Calibri",sans-serif'>From:</span></b><span style=3D'font-size:11=
.0pt;font-family:"Calibri",sans-serif'> Eric C Rosen [mailto:<a href=3D"mailto=
:erosen@juniper.net" target=3D"_blank">erosen@juniper.net</a>] <br><b>Sent:</b=
> Thursday, August 16, 2018 2:59 PM<br><b>To:</b> Linda Dunbar &lt;<a href=3D"=
mailto:linda.dunbar@huawei.com" target=3D"_blank">linda.dunbar@huawei.com</a>&=
gt;; <a href=3D"mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com</a>; <=
a href=3D"mailto:idr@ietf.org" target=3D"_blank">idr@ietf.org</a>; Jeff Tantsura=
 &lt;<a href=3D"mailto:jefftant.ietf@gmail.com" target=3D"_blank">jefftant.ietf@=
gmail.com</a>&gt;; RTGWG &lt;<a href=3D"mailto:rtgwg@ietf.org" target=3D"_blank"=
>rtgwg@ietf.org</a>&gt;<br><b>Subject:</b> Re: Preventing BGP Route leak (Hi=
jack) for Management Channel BGP session</span><o:p></o:p></p></div></div><p=
 class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>=
&nbsp;<o:p></o:p></p><p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;margi=
n-bottom:12.0pt'>On 8/13/2018 3:26 PM, Linda Dunbar wrote:<o:p></o:p></p><bl=
ockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'><p class=3DMsoNormal sty=
le=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>One of the comments =
to <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker=
.ietf.org_doc_draft-2Ddm-2Dnet2cloud-2Dgap-2Danalysis_&amp;d=3DDwMFAg&amp;c=3DHA=
kYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&amp;r=3D-DXB84eU9m4cIlq2OOcCJCQQAwJX=
QQswyu3F0kG0VNo&amp;m=3DRToh0UhV7F8cp3q2ud1LmU6GZtypPTJdboL4dgpRzr0&amp;s=3D9xbK=
Yj5fP6Jv93coe5g-lfzpp0L0bK0GyrlB91Ry3Sw&amp;e=3D" target=3D"_blank">https://data=
tracker.ietf.org/doc/draft-dm-net2cloud-gap-analysis/</a> the In RTGwg sessi=
on of IETF102 is that using BGP session to pass configuration keys for IPsec=
 can be risky even if the path between RR &amp; node is secure (say via TLS)=
 due to BGP route leak (Hijack). <o:p></o:p></p><p class=3DMsoNormal style=3D'ms=
o-margin-top-alt:auto;mso-margin-bottom-alt:auto'>But the BGP session to car=
ry IPsec configurations is via BGP management session, which is completely i=
solated form the dataplane BGP sessions.. <o:p></o:p></p></blockquote><p cla=
ss=3DMsoNormal style=3D'mso-margin-top-alt:auto;margin-bottom:12.0pt'><br>I'm no=
t sure I have the whole context, but the question seems to be whether it cou=
ld ever be safe to use BGP to distribute secret keys.<br><br>Presumably:<br>=
<br>- The keys would be carried in an attribute that can only be attached by=
 UPDATEs of a specified AFI/SAFI, where the specified AFI/SAFI is only used =
to carry management/configuration information.<br><br>- UPDATEs of that AFI/=
SAFI would only be sent on BGP sessions that are adequately secured so as to=
 provide privacy, integrity and authentication.<br><br>- The UPDATEs would c=
arry the NO_ADVERTISE community (to make sure they are not propagated furthe=
r).<br><br>- None of the BGP systems involved would allow any sort of &quot;=
BGP monitoring&quot; that might expose the unencrypted contents of the UPDAT=
Es.<br><br>In this scenario, I don't think it matters whether the secure BGP=
 session also carries other AFI/SAFIs.<br><br>The privacy properties of this=
 scenario are pretty good, in theory, but I don't think they are really good=
 enough for distributing secret keys.<br><br>- Once you're using BGP to dist=
ribute information, it is inevitable that someone will decide to remove the =
&quot;NO_ADVERTISE&quot; and allow the information to be propagated through =
intermediate nodes (RRs or ASBRs) to the actual target node.&nbsp; After all=
, one of the main values of using BGP to distribute stuff is that you get a =
big distribution system.&nbsp; Even if all the intermediate nodes are truste=
d and all the intermediate BGP sessions have adequate privacy/integrity/auth=
entication, you still wouldn't want to expose the secret keys to those nodes=
.&nbsp; You might trust those nodes to see all the routing information, and =
even to see most of the management information, but you probably don't want =
them to see all the secret keys.&nbsp; And you probably don't want the secre=
t keys stored in the clear on those intermediate nodes.<br><br>- I would wor=
ry about BGP monitoring procedures creating a backdoor through which the sec=
ret keys would be exposed.&nbsp; <br><br>- No matter how careful you are, wh=
en you use BGP you can be pretty sure that your UPDATEs will end up somewher=
e they're not supposed to go.&nbsp; It's just too easy to make mistakes.&nbs=
p; <br>So I don't think I'd try to do dynamic keying by attaching the actual=
 keys to BGP UPDATEs.&nbsp; At most I'd use BGP to distribute parameters tha=
t could then be used by something like IKEv2 to actually fetch the secret ke=
ys.<o:p></o:p></p></div></div><p class=3DMsoNormal style=3D'margin-bottom:12.0pt=
'><br>_______________________________________________<br>rtgwg mailing list<=
br><a href=3D"mailto:rtgwg@ietf.org">rtgwg@ietf.org</a><br><a href=3D"https://ww=
w.ietf.org/mailman/listinfo/rtgwg" target=3D"_blank">https://www.ietf.org/mail=
man/listinfo/rtgwg</a><o:p></o:p></p></blockquote></div><p class=3DMsoNormal>&=
nbsp;<o:p></o:p></p></div><p class=3DMsoNormal><span style=3D'font-size:11.0pt;f=
ont-family:"Calibri",sans-serif'>___________________________________________=
____ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo=
/rtgwg <o:p></o:p></span></p></div></body></html>

--B_3617362297_1312349409--



From nobody Mon Aug 20 06:58:08 2018
Return-Path: <internet-drafts@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40EE130FF0; Mon, 20 Aug 2018 06:57:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: idr@ietf.org
Message-ID: <153477347893.23135.16775622394916577641@ietfa.amsl.com>
Date: Mon, 20 Aug 2018 06:57:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kvu9VO522bvkB2TGbG0-WMx1CWs>
Subject: [Idr] I-D Action: draft-ietf-idr-tunnel-encaps-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2018 13:58:07 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing WG of the IETF.

        Title           : The BGP Tunnel Encapsulation Attribute
        Authors         : Eric C. Rosen
                          Keyur Patel
                          Gunter Van de Velde
	Filename        : draft-ietf-idr-tunnel-encaps-10.txt
	Pages           : 41
	Date            : 2018-08-20

Abstract:
   RFC 5512 defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute".  This attribute allows one to specify a set
   of tunnels.  For each such tunnel, the attribute can provide the
   information needed to create the tunnel and the corresponding
   encapsulation header.  The attribute can also provide information
   that aids in choosing whether a particular packet is to be sent
   through a particular tunnel.  RFC 5512 states that the attribute is
   only carried in BGP UPDATEs that have the "Encapsulation Subsequent
   Address Family (Encapsulation SAFI)".  This document deprecates the
   Encapsulation SAFI (which has never been used in production), and
   specifies semantics for the attribute when it is carried in UPDATEs
   of certain other SAFIs.  This document adds support for additional
   tunnel types, and allows a remote tunnel endpoint address to be
   specified for each tunnel.  This document also provides support for
   specifying fields of any inner or outer encapsulations that may be
   used by a particular tunnel.

   This document obsoletes RFC 5512.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-10
https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-tunnel-encaps-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Aug 29 00:02:13 2018
Return-Path: <mrajesh@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1612008A for <idr@ietfa.amsl.com>; Wed, 29 Aug 2018 00:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 kelXDcipDk5P for <idr@ietfa.amsl.com>; Wed, 29 Aug 2018 00:02:09 -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 48ABE128CF3 for <Idr@ietf.org>; Wed, 29 Aug 2018 00:02:09 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7T6xK41026715 for <Idr@ietf.org>; Wed, 29 Aug 2018 00:02:08 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=eoGGYGIpefQ8tv6BZbKZ88Cq88XSBhCNzUeK4T0Kzq8=; b=dCTTnvCNd1amvPkJgI9v3ZuIEnyQSK85zwGeKVTtn/odcqBoLRkMXCt5oOhpJBcrbQKd 0ghUqxhUnlUsDWzK9oZkWXJq77USGbuXGQtTL7ZmqanZRUPtfntrM5sU4obCN6z6/rVF EOAXEadX/EDGppCeIZjnf57O36/EhP9HZ3mv4wEwtKZd65wnw1c8uVG9q5hKalUqOA49 r84YCs/7Gy3OZmon3CXeFAZyiI4H0Sl40lcot2rNlTY50dM1UlDp1pTynoRFnWTRTG7d lFObYdQF/OmZgwrMdsalVRkDuVA8Fjyt65cIkUYou2oINvfi4OCcYg+QK+Z8XkJMIHvT FQ== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0112.outbound.protection.outlook.com [207.46.163.112]) by mx0b-00273201.pphosted.com with ESMTP id 2m5cx9rx0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <Idr@ietf.org>; Wed, 29 Aug 2018 00:02:08 -0700
Received: from BN3PR0501MB1251.namprd05.prod.outlook.com (10.160.183.142) by BN3PR0501MB1524.namprd05.prod.outlook.com (10.161.217.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.10; Wed, 29 Aug 2018 07:02:05 +0000
Received: from BN3PR0501MB1251.namprd05.prod.outlook.com ([fe80::6c66:7fa:aee7:b2ba]) by BN3PR0501MB1251.namprd05.prod.outlook.com ([fe80::6c66:7fa:aee7:b2ba%6]) with mapi id 15.20.1101.007; Wed, 29 Aug 2018 07:02:03 +0000
From: Rajesh M <mrajesh@juniper.net>
To: "Idr@ietf.org" <Idr@ietf.org>
CC: Balaji Rajagopalan <balajir@juniper.net>, Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
Thread-Index: AdQ/ZOjvqmWDxbGYSbWH0hgd2FdRNA==
Date: Wed, 29 Aug 2018 07:02:03 +0000
Message-ID: <BN3PR0501MB125186FB87889FCC0005E19BBE090@BN3PR0501MB1251.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [116.197.184.11]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1524; 6:mHniOHlNDr7JdqHZsKA0bAVJ3KjO/r8amxqp/B8noJBXxu25IXhvjsXcHs89NI0HzxTzAjN1RpM/U3xQu0uvb1ZicLZqY54D2NOtAg6N3cykZhPiyfsiC3sgcOhFiKgObyiQKMolIMzaK9I6GiiD7K7jQT6zHDya0MSg5usN3qYPVSUyjM4yz9gKvL0dppZ+wlSLXAVM/LmAys48c6SeAW4XwU3bEhEWmYk2rjw1d8DqCYG42RYHaweXYVOX0HOhY1j8ADX8eRiLucQ9R7nTLmHgQggWeYy6xqNzhAuKdPXsXY2U6HsX1mLrW7UjUJE4jnx6KISOsKWGIC/BqXLMS5sUBEm264kGmGXBzVGqtlPEFhlx45vSd4cbOkK0VyUyOIpat7r3bsqpXVc/XtbasecdhUj1doaJSHNhXBb2opWqnuJLJM1jDiefeFl105Sk25POUDknRVDc9dFx4+0YUA==; 5:3a8Lmy7EMEC9ZxUiP1LI7W1cNeA4DhMhmoKmo5pn2s2jRJNBHtNmN8Qr4tcx8MPoDW6bW86CraZ75N96WRs++KGiKIvExEkNex5tkGCI2U7PCAGjtamuolq1MdlC9808MpXAnjn+FU8jbekutnMW400UGAMm6fWJqtUJ4ylST08=; 7:oJIDWGlj2wX6fbg2iXbFhEq+dFndttPL1iMpeqSXJkPpNJJGc/NKhq+kzXF01fTZXyRofgi9aMyllMCBVm5cElLfsIQmbauk07Rh3P4Cgie+wf6kODLbQsFqaqLC+LiHSYQPPR9KFlpIfS6tMo1kbLKKrGlR/p7hHsG0UYfQ8+RLKzpxeWB/AvTJCoqB0zkKcbv1IXjGkfKYSJ7nEuDcDwlQ5FQ9v/RfviLrG9BQkjC3Fks4Bqnf+BTZfzxdHqr4
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(366004)(346002)(396003)(189003)(199004)(102836004)(2906002)(486006)(68736007)(4326008)(476003)(2501003)(106356001)(305945005)(99286004)(7736002)(74316002)(86362001)(66066001)(6346003)(7696005)(54906003)(316002)(8936002)(81156014)(81166006)(14454004)(8676002)(6916009)(6506007)(26005)(966005)(186003)(5660300001)(5640700003)(9686003)(53936002)(478600001)(6436002)(55016002)(256004)(6306002)(97736004)(6116002)(3846002)(2351001)(5250100002)(25786009)(105586002)(33656002)(107886003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1524; H:BN3PR0501MB1251.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
x-ms-office365-filtering-correlation-id: 4d25e723-5b6e-4d9f-257e-08d60d7d5356
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN3PR0501MB1524; 
x-ms-traffictypediagnostic: BN3PR0501MB1524:
x-microsoft-antispam-prvs: <BN3PR0501MB15249FC1991413EAC2B7A628BE090@BN3PR0501MB1524.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301075)(3002001)(10201501046)(93006095)(93001095)(3231340)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699049)(76991033); SRVR:BN3PR0501MB1524; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1524; 
x-forefront-prvs: 077929D941
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: i1vNopKuUNB7B0MKZta1M/yToWQv5kGmc0ZXF4nb+I7sKmCkEflfCEHw3wI/uhnnkFMk8VZAfLEiLa0NWqND6QqaqTMAgWqpcJoAQZa2pq7nLDQO+LNhZTKFSqdre/3DNNw0ON6hNQ6+0CIedDE0y7nMK6QdslWp/ZmUZ0Cb+suq9sb9fjxVNqzqONa3mdnc4bRzX5hhAf0uwqaDBzcuTYHTxBl4iTctW5SzHmlKpGMMujSjp6kFJ4DxSO/X53XL/nwoQFiqzZnbAPbzXM8pwb8EEPsBDHaqKaYRRZ8Q+x11xv1EJFfqYRruTzBRz7QOM8FeVanUzig9drYgft5WtSuuVOLZLjibvqlw4yEm2GY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB125186FB87889FCC0005E19BBE090BN3PR0501MB1251_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d25e723-5b6e-4d9f-257e-08d60d7d5356
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2018 07:02:03.7419 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1524
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-29_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=590 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808290077
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/43Ksfci7pkxMKPBsPT_hSIyeI8Y>
Subject: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 07:02:12 -0000

--_000_BN3PR0501MB125186FB87889FCC0005E19BBE090BN3PR0501MB1251_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

About section 2.2.1 (Adjacency SID TLV) section 2.2.2 (LAN Adjacency SID TL=
V):
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.

About section 2.3.1 (Prefix-SID TLV) :
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.

Our understanding is
Protocol cannot be got from Node NLRI Format, Link NLRI Format, Prefix NLRI=
 Format since multiple NLRIs can share same set of BGP-LS attribute.



--_000_BN3PR0501MB125186FB87889FCC0005E19BBE090BN3PR0501MB1251_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>About section 2.2.1 (Adjacency SID TLV) section 2.2.2 (LAN Adjacency S=
ID TLV):</div>
<div>Here Flags field is specific to OSPF and ISIS. Until we know the proto=
col we will not be able to decode the received Flags.</div>
<div>&nbsp;</div>
<div>About section 2.3.1 (Prefix-SID TLV) :</div>
<div>Here Flags field is specific to OSPF and ISIS. Until we know the proto=
col we will not be able to decode the received Flags.</div>
<div>&nbsp;</div>
<div>Our understanding is </div>
<div><font color=3D"#5B9BD5"><b>Protocol cannot be got from </b><b>Node NLR=
I Forma</b><b>t,</b><b> Link NLRI Format</b><b>, </b><b>Prefix NLRI Format<=
/b><b> since multiple NLRIs can share same set of </b><b>BGP-LS attribute</=
b><b>.</b></font></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_BN3PR0501MB125186FB87889FCC0005E19BBE090BN3PR0501MB1251_--


From nobody Thu Aug 30 07:17:50 2018
Return-Path: <ietf-ipr@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3557C130E84; Thu, 30 Aug 2018 07:17:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat <ietf-ipr@ietf.org>
To: <draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org>
Cc: idr@ietf.org, ipr-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153563866821.3301.7231582049581225173@ietfa.amsl.com>
Date: Thu, 30 Aug 2018 07:17:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/--DT9zgesOkQy-SfKd_2tshUb2g>
Subject: [Idr] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-idr-bgp-ls-segment-routing-msd
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 14:17:48 -0000

Dear Jeff Tantsura, Uma Chunduri, Gregory Mirsky, Siva Sivabalan:


An IPR disclosure that pertains to your Internet-Draft entitled
"Signaling MSD (Maximum SID Depth) using Border Gateway Protocol
Link-State" (draft-ietf-idr-bgp-ls-segment-routing-msd) was submitted to
the IETF Secretariat on  and has been posted on the "IETF Page of
Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3273/). The title of the IPR disclosure is
"Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to
draft-ietf-idr-bgp-ls-segment-routing-msd"


Thank you

IETF Secretariat


From nobody Thu Aug 30 18:48:33 2018
Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310C130DFC for <idr@ietfa.amsl.com>; Thu, 30 Aug 2018 18:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EDd6UYJs0JLP for <idr@ietfa.amsl.com>; Thu, 30 Aug 2018 18:48:30 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271C3130DF4 for <Idr@ietf.org>; Thu, 30 Aug 2018 18:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8976; q=dns/txt; s=iport; t=1535680110; x=1536889710; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZuwPeN1WfpwPhEjuvaDHMUFoVefYpxmsvkDBLMltqxc=; b=BMQ99PXNUMmmBiToKFhYucfQdnyUMJ5CQKaxs00vmctK2oRcoPYgbCNi yj06ERPzgCN+Stkaq9Whfk8DtzVTAsFy5u1E7ToFAEz2V9BaGNW+RJzgY iIrvRy13zjZmiGaJpUsXK8rrjtqJdBUdflrP1odSoJkWauugNFeyYjrJu k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAACmnYhb/4ENJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXeGV/KAqLeY44kHaFM4F6C4RsAoMjITQYAQIBAQIBAQJ?= =?us-ascii?q?tKIU3AQEBAQMtTBACAQgRBAEBLzIdCAEBBAENBQiDGoEdZKQqigKKEReBQT+?= =?us-ascii?q?BEoMSilYCjROFVIhWCQKPax+BP4Q0h0OBHIg6ingCERSBJB04gVJwFYMkgiU?= =?us-ascii?q?XEY4Gb4wQgRwBAQ?=
X-IronPort-AV: E=Sophos;i="5.53,309,1531785600";  d="scan'208,217";a="443745428"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 01:48:29 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w7V1mTcG029960 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2018 01:48:29 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 30 Aug 2018 20:48:28 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1367.000; Thu, 30 Aug 2018 20:48:28 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Rajesh M <mrajesh@juniper.net>, "Idr@ietf.org" <Idr@ietf.org>
CC: Shraddha Hegde <shraddha@juniper.net>
Thread-Topic: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
Thread-Index: AdQ/ZOjvqmWDxbGYSbWH0hgd2FdRNABZ0uQw
Date: Fri, 31 Aug 2018 01:48:28 +0000
Message-ID: <1b8c5b39e54e4cdc8c4237dc2167f2e0@XCH-ALN-008.cisco.com>
References: <BN3PR0501MB125186FB87889FCC0005E19BBE090@BN3PR0501MB1251.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR0501MB125186FB87889FCC0005E19BBE090@BN3PR0501MB1251.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.69.238]
Content-Type: multipart/alternative; boundary="_000_1b8c5b39e54e4cdc8c4237dc2167f2e0XCHALN008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6Benv4GEcp4-aFe_ZNr98O3uRvo>
Subject: Re: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2018 01:48:32 -0000

--_000_1b8c5b39e54e4cdc8c4237dc2167f2e0XCHALN008ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rajesh,

Please check inline below.

From: Idr <idr-bounces@ietf.org> On Behalf Of Rajesh M
Sent: 29 August 2018 12:32
To: Idr@ietf.org
Cc: Shraddha Hegde <shraddha@juniper.net>
Subject: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-Stat=
e extensions for Segment Routing )

About section 2.2.1 (Adjacency SID TLV) section 2.2.2 (LAN Adjacency SID TL=
V):
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

About section 2.3.1 (Prefix-SID TLV) :
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

Our understanding is
Protocol cannot be got from Node NLRI Format, Link NLRI Format, Prefix NLRI=
 Format since multiple NLRIs can share same set of BGP-LS attribute.
[KT] This is about packing of BGP-LS updates. Since each BGP-LS NLRI has a =
unique set of attributes, it is not possible to pack multiple NLRIs in the =
same update. Doing this for NLRIs across protocol is even harder. The updat=
e messages end up being a single NLRI and its attributes. Would you agree? =
And as an extension we know the protocol when decoding the flags.

Thanks,
Ketan




--_000_1b8c5b39e54e4cdc8c4237dc2167f2e0XCHALN008ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi Rajesh,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Please check inline be=
low.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Idr &lt;idr-bounces@ietf.org&g=
t;
<b>On Behalf Of </b>Rajesh M<br>
<b>Sent:</b> 29 August 2018 12:32<br>
<b>To:</b> Idr@ietf.org<br>
<b>Cc:</b> Shraddha Hegde &lt;shraddha@juniper.net&gt;<br>
<b>Subject:</b> [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Li=
nk-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.2.1 (Adjacency SID TLV) section 2.2=
.2 (LAN Adjacency SID TLV):<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.3.1 (Prefix-SID TLV) :<o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Our understanding is
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:#5B9BD5">Protocol cannot be got from Node N=
LRI Format, Link NLRI Format, Prefix NLRI Format since multiple NLRIs can s=
hare same set of BGP-LS attribute.</span></b><b><span style=3D"font-size:11=
.0pt;font-family:&quot;Calibri&quot;,sans-serif"><o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] This is about packing of B=
GP-LS updates. Since each BGP-LS NLRI has a unique set of attributes, it is=
 not possible to pack multiple NLRIs in the same
 update. Doing this for NLRIs across protocol is even harder. The update me=
ssages end up being a single NLRI and its attributes. Would you agree? And =
as an extension we know the protocol when decoding the flags.<o:p></o:p></s=
pan></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></i></b=
></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Thanks,<o:p></o:p></span></i></=
b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Ketan<o:p></o:p></span></i></b>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_1b8c5b39e54e4cdc8c4237dc2167f2e0XCHALN008ciscocom_--


From nobody Thu Aug 30 22:52:32 2018
Return-Path: <mrajesh@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90427130E10 for <idr@ietfa.amsl.com>; Thu, 30 Aug 2018 22:52:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 zpw59_9dfDRk for <idr@ietfa.amsl.com>; Thu, 30 Aug 2018 22:52:28 -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 05AF512872C for <Idr@ietf.org>; Thu, 30 Aug 2018 22:52:27 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7V5msIf013779; Thu, 30 Aug 2018 22:52:25 -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=yTmgHe+Bjcpzhv/+gMlsm48QEt7sr3Ed0xROtiBHF5g=; b=W/FIOAEWit1pDjIh6gVT4cth31A5qBQR6gkd2u1z8cKc9A/qGBmFRD+zTcMkEJn9KwQX EZCeIu4U0GQWTXhT36Fu5K8jgi6Axwigv2nRhR3T+J5m9LZ+sx4yBzgFNYGlwVIPHJYn V+9G2c+eqVXPUMSjUB0vaQyxQE/nHDSXX5JV+Ls1cVAKcMHioVCgnUl8r+H5AmHeCQ4p ApsZ+qNmAvPtZ95KlB/5sOLbaRv5B3rcktjUg1x2XvRIWjh5/uR2LVGrbygHrL7/kznZ 3MOkdYpQp6rpqfg6KRes3TTLiIDK/fRvsYrMmqroapunkpLqAdQ6Ipee016r0Zr9tXlD Mw== 
Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0082.outbound.protection.outlook.com [216.32.181.82]) by mx0a-00273201.pphosted.com with ESMTP id 2m6ydw819g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 22:52:25 -0700
Received: from BN3PR0501MB1251.namprd05.prod.outlook.com (10.160.183.142) by BN3PR0501MB1410.namprd05.prod.outlook.com (10.160.117.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.8; Fri, 31 Aug 2018 05:52:22 +0000
Received: from BN3PR0501MB1251.namprd05.prod.outlook.com ([fe80::6c66:7fa:aee7:b2ba]) by BN3PR0501MB1251.namprd05.prod.outlook.com ([fe80::6c66:7fa:aee7:b2ba%6]) with mapi id 15.20.1101.016; Fri, 31 Aug 2018 05:52:20 +0000
From: Rajesh M <mrajesh@juniper.net>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "Idr@ietf.org" <Idr@ietf.org>
CC: Shraddha Hegde <shraddha@juniper.net>, Ram Santhanakrishnan <ramsk@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>
Thread-Topic: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
Thread-Index: AdQ/ZOjvqmWDxbGYSbWH0hgd2FdRNABZ0uQwAAiPZqA=
Date: Fri, 31 Aug 2018 05:52:20 +0000
Message-ID: <BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0@BN3PR0501MB1251.namprd05.prod.outlook.com>
References: <BN3PR0501MB125186FB87889FCC0005E19BBE090@BN3PR0501MB1251.namprd05.prod.outlook.com> <1b8c5b39e54e4cdc8c4237dc2167f2e0@XCH-ALN-008.cisco.com>
In-Reply-To: <1b8c5b39e54e4cdc8c4237dc2167f2e0@XCH-ALN-008.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [116.197.184.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1410; 6:J5ZJnZXnOstwFdXG6z8LYeSwyk2f9l83gtO0SECU3SMRbjofIGGAmxFins0UeYnESv0yRzndxmoKQqSIIJAlPOBa6f1fca6wpyYlxHeUWDLZWm3SOVmrU6DMlvjI6h58JCnqR2PfMWxUZd2sFs+JZfzXEX4rc+h4mWpekmd7vW7mZihufkIX+hnfOum3RnVCjzOps3A0Gh3yaHDxkOWDJCXadzM+TYCln8nZ4MrXofKRHLi3gi24GPzD2qjMK72Yij9CnuQvPMkPn1pYQ7tweF0twmuGSBQ5Moynq70WfS+KfCwUpgkVb2+xDM4I9m2kMGsh6unV1uZrA1gfrTVp64JitxIpd+RC2iptG0kkuObDhurjfMv8/oPTG4Bhn+d0kqwev7etGps9fauRZCUrdpPi0TjHdOmfkjcesiG+b6J6sey7Kq5Uo3GLscO2fXMlGzugQoHRiBuQcc/r8JXRGg==; 5:kY9JdLOylDQMBm4DL5GozQvJRACGyM1vsik58rAKcSUz0B2/KoA+o+tD0tBaibEWZtIC5s+KHelA9efd4FobxdSUSlf606J0ayjom6b6dtD4xi2aV/B5cx5cocvHYhZ4E6eHR+QyYGFb/uRcQtPHeWTuRTzLOtYvkV7YQLwJKt4=; 7:yuuHLBlp/j/XnKB8sU88fpy0DvMZZKLLk8GS31SEEkaN0+uTHwu1+bNH69bMJapX7JDqLjGYWaf9sj0Gzg69fnk7Pdw/2pDE7VhUPQcueSr1IXSehfxz2llWcBxRetKPcubJLvzwqLU9DGlzoLReT42tD4sCu0vU7tBDocd9PMsr7WEBusZu82vFwzwgrGlLdB12OfqgU1TxdPPfKoBggGh7+Nv1LJhwkJV83luwR0fbqAmUA4ln/qqKwcctG5Jx
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(376002)(346002)(396003)(199004)(189003)(105586002)(316002)(68736007)(7736002)(446003)(478600001)(54906003)(7696005)(6246003)(476003)(486006)(11346002)(110136005)(66066001)(5660300001)(33656002)(99286004)(25786009)(6506007)(53546011)(229853002)(186003)(8936002)(53936002)(2501003)(236005)(102836004)(76176011)(26005)(5250100002)(6346003)(6436002)(2900100001)(81156014)(790700001)(81166006)(3846002)(256004)(107886003)(2906002)(74316002)(4326008)(55016002)(6306002)(106356001)(54896002)(14444005)(14454004)(6116002)(9326002)(9686003)(86362001)(97736004)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1410; H:BN3PR0501MB1251.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
x-ms-office365-filtering-correlation-id: 1d09bf60-ca47-4071-7cc1-08d60f05eab8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(4534165)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN3PR0501MB1410; 
x-ms-traffictypediagnostic: BN3PR0501MB1410:
x-microsoft-antispam-prvs: <BN3PR0501MB1410AE7EA2819A604A961A02BE0F0@BN3PR0501MB1410.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(138986009662008)(95692535739014)(21748063052155); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(823301075)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699049)(76991033); SRVR:BN3PR0501MB1410; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1410; 
x-forefront-prvs: 07817FCC2D
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: CUwUm62mqdFbvLCsgQgMk/YrytjwVmseuLe0lyx7ycoUWWPRVNlVq97417grhnFnSQNevwM2YknFvuUdtfntFbN2CB3HZcvo5SHbP7vnLZijqCfZRxCIAocnsNy+KGmw3CtaP9hcbNo2Mf35oHbtlF2T8nAerw0uMZAYwd7ThT51HPhzyZM0tkLHh/+DP4UcsGRT27ic2KZLqEfQnp5LYKzbm+2GFmsmHPZ5kIwYAtkKrqPozZy/pG14rhzY6bcDg0xe7v27EWAjA5H6kVF0auxdXsiTtE2t94juUSwEFK3TacdAMW8f5D4wHOZvC45UNWEbBdQID8xUUdWBZVPCscKUtecxCTtV/o42xFAqUlM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0BN3PR0501MB1251_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d09bf60-ca47-4071-7cc1-08d60f05eab8
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2018 05:52:20.4684 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1410
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-31_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808310062
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/wMREjV2zP3w2CM_0WEHjr4aoXWc>
Subject: Re: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2018 05:52:31 -0000

--_000_BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0BN3PR0501MB1251_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Ketan,

Attributes might end Up same even across protocol (OSPF/ISIS). It's not goo=
d to make that Assumption.
our suggestion is to : Mandatory add protocol as part of the Node/Link/Pref=
ix attributes to ensure the same.

Thanks
Rajesh

From: Ketan Talaulikar (ketant) <ketant@cisco.com>
Sent: Friday, August 31, 2018 7:18 AM
To: Rajesh M <mrajesh@juniper.net>; Idr@ietf.org
Cc: Shraddha Hegde <shraddha@juniper.net>
Subject: RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State =
extensions for Segment Routing )

Hi Rajesh,

Please check inline below.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of =
Rajesh M
Sent: 29 August 2018 12:32
To: Idr@ietf.org<mailto:Idr@ietf.org>
Cc: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-Stat=
e extensions for Segment Routing )

About section 2.2.1 (Adjacency SID TLV) section 2.2.2 (LAN Adjacency SID TL=
V):
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

About section 2.3.1 (Prefix-SID TLV) :
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

Our understanding is
Protocol cannot be got from Node NLRI Format, Link NLRI Format, Prefix NLRI=
 Format since multiple NLRIs can share same set of BGP-LS attribute.
[KT] This is about packing of BGP-LS updates. Since each BGP-LS NLRI has a =
unique set of attributes, it is not possible to pack multiple NLRIs in the =
same update. Doing this for NLRIs across protocol is even harder. The updat=
e messages end up being a single NLRI and its attributes. Would you agree? =
And as an extension we know the protocol when decoding the flags.

Thanks,
Ketan




--_000_BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0BN3PR0501MB1251_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Hi Ketan,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Attributes might end Up same even acr=
oss protocol (OSPF/ISIS). It&#8217;s not good to make that Assumption.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">our suggestion is to : Mandatory add =
protocol as part of the Node/Link/Prefix attributes to ensure the same.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Thanks<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Rajesh<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Ketan Talaulikar (ketant) &lt;=
ketant@cisco.com&gt;
<br>
<b>Sent:</b> Friday, August 31, 2018 7:18 AM<br>
<b>To:</b> Rajesh M &lt;mrajesh@juniper.net&gt;; Idr@ietf.org<br>
<b>Cc:</b> Shraddha Hegde &lt;shraddha@juniper.net&gt;<br>
<b>Subject:</b> RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link=
-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi Rajesh,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Please check inline be=
low.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in =
0in 0in">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Idr &lt;<a href=3D"mailto:idr-=
bounces@ietf.org">idr-bounces@ietf.org</a>&gt;
<b>On Behalf Of </b>Rajesh M<br>
<b>Sent:</b> 29 August 2018 12:32<br>
<b>To:</b> <a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<b>Cc:</b> Shraddha Hegde &lt;<a href=3D"mailto:shraddha@juniper.net">shrad=
dha@juniper.net</a>&gt;<br>
<b>Subject:</b> [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Li=
nk-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.2.1 (Adjacency SID TLV) section 2.2=
.2 (LAN Adjacency SID TLV):<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.3.1 (Prefix-SID TLV) :<o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Our understanding is
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:#5B9BD5">Protocol cannot be got from Node N=
LRI Format, Link NLRI Format, Prefix NLRI Format since multiple NLRIs can s=
hare same set of BGP-LS attribute.</span></b><b><span style=3D"font-size:11=
.0pt;font-family:&quot;Calibri&quot;,sans-serif"><o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] This is about packing of B=
GP-LS updates. Since each BGP-LS NLRI has a unique set of attributes, it is=
 not possible to pack multiple NLRIs in the same
 update. Doing this for NLRIs across protocol is even harder. The update me=
ssages end up being a single NLRI and its attributes. Would you agree? And =
as an extension we know the protocol when decoding the flags.<o:p></o:p></s=
pan></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></i></b=
></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Thanks,<o:p></o:p></span></i></=
b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Ketan<o:p></o:p></span></i></b>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0BN3PR0501MB1251_--


From nobody Fri Aug 31 00:51:22 2018
Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D42128CF2 for <idr@ietfa.amsl.com>; Fri, 31 Aug 2018 00:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 svTU1rT3k0Qx for <idr@ietfa.amsl.com>; Fri, 31 Aug 2018 00:51:17 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DF712872C for <Idr@ietf.org>; Fri, 31 Aug 2018 00:51:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15820; q=dns/txt; s=iport; t=1535701876; x=1536911476; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aqtqHZyM832sRejqxnl0bU+/MS678UWDuUtivCAgD04=; b=Gf92iUp2ftlK9AqEfEgsc4hE4NLq22XZI0AfICkXlkVtwZAB/8Rz5rh2 pj6j74Oa4QE75Q5UWdwOgr//dPffc+sMyLJMd6BduHoqkSFbqduwgaLPl N97LhSDNg5mxI4sSlF0Vtg4c2gSA3gn4xk0YqdSKk4a3bu7VYZTKQBKb/ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaAADq8ohb/5RdJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJXeGV/KAqLeY44kHaFM4F6C4RsAoMpITQYAQIBAQIBAQJ?= =?us-ascii?q?tKIU3AQEBAQMtRwUQAgEIEQQBASgHMhQJCAEBBAENBQiDGoEdZKNUigOKERe?= =?us-ascii?q?BQT+BEoMShTSFIgKNE4VUiFYJAo9rH4E/hDSHQ4EciDqKeAIRFIEkHTiBUnA?= =?us-ascii?q?VgySCJRcRjgZvjBCBHAEB?=
X-IronPort-AV: E=Sophos;i="5.53,309,1531785600";  d="scan'208,217";a="435471689"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 07:51:15 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id w7V7pFVA006780 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2018 07:51:15 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 31 Aug 2018 02:51:14 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1367.000; Fri, 31 Aug 2018 02:51:14 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Rajesh M <mrajesh@juniper.net>, "Idr@ietf.org" <Idr@ietf.org>
CC: Shraddha Hegde <shraddha@juniper.net>, Ram Santhanakrishnan <ramsk@juniper.net>, Balaji Rajagopalan <balajir@juniper.net>
Thread-Topic: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
Thread-Index: AdQ/ZOjvqmWDxbGYSbWH0hgd2FdRNABZ0uQwAAiPZqAAApUB0A==
Date: Fri, 31 Aug 2018 07:51:14 +0000
Message-ID: <35adb6bae30a4ea88decef19ee51c6c9@XCH-ALN-008.cisco.com>
References: <BN3PR0501MB125186FB87889FCC0005E19BBE090@BN3PR0501MB1251.namprd05.prod.outlook.com> <1b8c5b39e54e4cdc8c4237dc2167f2e0@XCH-ALN-008.cisco.com> <BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0@BN3PR0501MB1251.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR0501MB1251EDECC0D1AA439AF0AA11BE0F0@BN3PR0501MB1251.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.69.238]
Content-Type: multipart/alternative; boundary="_000_35adb6bae30a4ea88decef19ee51c6c9XCHALN008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.19, xch-aln-009.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/l2AdI3Gww6HylJ8yGpH1k_0hkLA>
Subject: Re: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State extensions for Segment Routing )
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2018 07:51:20 -0000

--_000_35adb6bae30a4ea88decef19ee51c6c9XCHALN008ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Rajesh,

There is also a problem with your suggestion. The moment we add protocol to=
 the attribute it can no longer be shared between NLRIs across protocols in=
 any case. So I don't see how it helps in the BGP packing.

There are several implementations of this draft which are shipping and depl=
oyed. So changing encodings in a manner that is not backward compatible is =
a challenge at this stage.

Thanks,
Ketan

From: Rajesh M <mrajesh@juniper.net>
Sent: 31 August 2018 11:22
To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Idr@ietf.org
Cc: Shraddha Hegde <shraddha@juniper.net>; Ram Santhanakrishnan <ramsk@juni=
per.net>; Balaji Rajagopalan <balajir@juniper.net>
Subject: RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State =
extensions for Segment Routing )

Hi Ketan,

Attributes might end Up same even across protocol (OSPF/ISIS). It's not goo=
d to make that Assumption.
our suggestion is to : Mandatory add protocol as part of the Node/Link/Pref=
ix attributes to ensure the same.

Thanks
Rajesh

From: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Sent: Friday, August 31, 2018 7:18 AM
To: Rajesh M <mrajesh@juniper.net<mailto:mrajesh@juniper.net>>; Idr@ietf.or=
g<mailto:Idr@ietf.org>
Cc: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-State =
extensions for Segment Routing )

Hi Rajesh,

Please check inline below.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of =
Rajesh M
Sent: 29 August 2018 12:32
To: Idr@ietf.org<mailto:Idr@ietf.org>
Cc: Shraddha Hegde <shraddha@juniper.net<mailto:shraddha@juniper.net>>
Subject: [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link-Stat=
e extensions for Segment Routing )

About section 2.2.1 (Adjacency SID TLV) section 2.2.2 (LAN Adjacency SID TL=
V):
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

About section 2.3.1 (Prefix-SID TLV) :
Here Flags field is specific to OSPF and ISIS. Until we know the protocol w=
e will not be able to decode the received Flags.
[KT] Ack

Our understanding is
Protocol cannot be got from Node NLRI Format, Link NLRI Format, Prefix NLRI=
 Format since multiple NLRIs can share same set of BGP-LS attribute.
[KT] This is about packing of BGP-LS updates. Since each BGP-LS NLRI has a =
unique set of attributes, it is not possible to pack multiple NLRIs in the =
same update. Doing this for NLRIs across protocol is even harder. The updat=
e messages end up being a single NLRI and its attributes. Would you agree? =
And as an extension we know the protocol when decoding the flags.

Thanks,
Ketan




--_000_35adb6bae30a4ea88decef19ee51c6c9XCHALN008ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
	{mso-style-name:msonormal;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman",serif;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri",sans-serif;
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi Rajesh,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">There is also a proble=
m with your suggestion. The moment we add protocol to the attribute it can =
no longer be shared between NLRIs across protocols
 in any case. So I don&#8217;t see how it helps in the BGP packing.<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">There are several impl=
ementations of this draft which are shipping and deployed. So changing enco=
dings in a manner that is not backward compatible
 is a challenge at this stage.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Thanks,<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Ketan<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Rajesh M &lt;mrajesh@juniper.n=
et&gt;
<br>
<b>Sent:</b> 31 August 2018 11:22<br>
<b>To:</b> Ketan Talaulikar (ketant) &lt;ketant@cisco.com&gt;; Idr@ietf.org=
<br>
<b>Cc:</b> Shraddha Hegde &lt;shraddha@juniper.net&gt;; Ram Santhanakrishna=
n &lt;ramsk@juniper.net&gt;; Balaji Rajagopalan &lt;balajir@juniper.net&gt;=
<br>
<b>Subject:</b> RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link=
-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Hi Ketan,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Attributes might end Up same even acr=
oss protocol (OSPF/ISIS). It&#8217;s not good to make that Assumption.<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">our suggestion is to : Mandatory add =
protocol as part of the Node/Link/Prefix attributes to ensure the same.<o:p=
></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Thanks<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D">Rajesh<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Ketan Talaulikar (ketant) &lt;=
<a href=3D"mailto:ketant@cisco.com">ketant@cisco.com</a>&gt;
<br>
<b>Sent:</b> Friday, August 31, 2018 7:18 AM<br>
<b>To:</b> Rajesh M &lt;<a href=3D"mailto:mrajesh@juniper.net">mrajesh@juni=
per.net</a>&gt;;
<a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<b>Cc:</b> Shraddha Hegde &lt;<a href=3D"mailto:shraddha@juniper.net">shrad=
dha@juniper.net</a>&gt;<br>
<b>Subject:</b> RE: draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Link=
-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Hi Rajesh,<o:p></o:p><=
/span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D">Please check inline be=
low.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-IN" style=3D"font-size:11.0pt;font-=
family:&quot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></spa=
n></p>
<div>
<div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Idr &lt;<a href=3D"mailto:idr-=
bounces@ietf.org">idr-bounces@ietf.org</a>&gt;
<b>On Behalf Of </b>Rajesh M<br>
<b>Sent:</b> 29 August 2018 12:32<br>
<b>To:</b> <a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<b>Cc:</b> Shraddha Hegde &lt;<a href=3D"mailto:shraddha@juniper.net">shrad=
dha@juniper.net</a>&gt;<br>
<b>Subject:</b> [Idr] draft-ietf-idr-bgp-ls-segment-routing-ext-08 ( BGP Li=
nk-State extensions for Segment Routing )<o:p></o:p></span></p>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.2.1 (Adjacency SID TLV) section 2.2=
.2 (LAN Adjacency SID TLV):<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">About section 2.3.1 (Prefix-SID TLV) :<o:p></o:p></=
span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Here Flags field is specific to OSPF and ISIS. Unti=
l we know the protocol we will not be able to decode the received Flags.<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] Ack</span></i></b><span st=
yle=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif;color:#1=
F497D"><o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">Our understanding is
<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif;color:#5B9BD5">Protocol cannot be got from Node N=
LRI Format, Link NLRI Format, Prefix NLRI Format since multiple NLRIs can s=
hare same set of BGP-LS attribute.</span></b><b><span style=3D"font-size:11=
.0pt;font-family:&quot;Calibri&quot;,sans-serif"><o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">[KT] This is about packing of B=
GP-LS updates. Since each BGP-LS NLRI has a unique set of attributes, it is=
 not possible to pack multiple NLRIs in the same
 update. Doing this for NLRIs across protocol is even harder. The update me=
ssages end up being a single NLRI and its attributes. Would you agree? And =
as an extension we know the protocol when decoding the flags.<o:p></o:p></s=
pan></i></b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></i></b=
></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Thanks,<o:p></o:p></span></i></=
b></p>
<p class=3D"MsoNormal"><b><i><span style=3D"font-size:11.0pt;font-family:&q=
uot;Calibri&quot;,sans-serif;color:#1F497D">Ketan<o:p></o:p></span></i></b>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">&nbsp;<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_35adb6bae30a4ea88decef19ee51c6c9XCHALN008ciscocom_--