From nobody Thu Dec 7 13:12:04 2017 Return-Path: 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 DE1FC1241FC; Thu, 7 Dec 2017 13:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 cfnVG-o98bHC; Thu, 7 Dec 2017 13:12:00 -0800 (PST) Received: from mail-ot0-x242.google.com (mail-ot0-x242.google.com [IPv6:2607:f8b0:4003:c0f::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 73727128DF3; Thu, 7 Dec 2017 13:12:00 -0800 (PST) Received: by mail-ot0-x242.google.com with SMTP id h9so7571043oti.0; Thu, 07 Dec 2017 13:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=h38kZHWL7EbPY1Ajy6WvrasFYCjp7We1nPmE+ccUy3k=; b=Xi1EOVd64bOB2TAYAk4zW1gHUP/n3FCc5st5jo8EhG1hBBPTZ3zhLb6yd3RF57CJed 6MSAiSPQb5OQ8ljM84G7zWz/NS+SPdicrKFJC3XSFPkrnUQiUbHyo3/wJgxdtVcB5QBs 6O1zSnkUGEfFplVLJKzMrNikwJWyRyjr+ssgZ3g46DKNO73gTERfE7W4cleeILXHwEqw sc8qoUoRL0ULJgfjXR2CIm41C8N295O0cMtg9hznXXrcgTpQJE5SvpuQb3xOylFUW7qs VEb4UX7ddc9ft6ExiWYTpWl/YNHUyFr1EPwm3PmXiHgi+ScntnXBI7jL9n2ybWZ8K1y4 yWHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=h38kZHWL7EbPY1Ajy6WvrasFYCjp7We1nPmE+ccUy3k=; b=oIzucD77FlbpXqW+et4USKWGGNhJKuSfQ58IhOU1nRBkNksm0RpiyWhFsbUJGO01fY Kd+5N9twLW+Krvx1UTtbZKKSwsFyPm80yH1r+PVQ50l/ErVbWMxnsByZsF6q8kGszKyM DkE+ockjU6/hxKkKXoUbHRVcMI3Z+N6VNtds6h4mgCXax1F5/9TZ/HqkAcxn4rK/DXYY CDGJtRDdCWXg/ULzBqp0xmiK9tnIxakv/6zq6gasA00vTko6X9WWuOohKMIFn4aR3qhG adpWmyiNdC93i60eDEOquM4fcV8hT0LA+PIPQN2hRXfw7vTs7vaR2QlUgPxgy1vbQuv5 vlBw== X-Gm-Message-State: AJaThX7qoazgWNfQ80sG8PJT2SMHlNg9k8HfH+uMYJ8aqKcnHXLQ+4kH tHJxDRS6FQpnwEK2gVP4ZXeT6crWyM4FD6Inldw= X-Google-Smtp-Source: AGs4zMYqzbqHNxGNwlO6RFd3r9vUtBqrvbe0NQ616rfxHKZTK2fD1IHnpo+0pf9QNGx+NSs46j0TnIQcBRn1gDge+1Q= X-Received: by 10.157.56.200 with SMTP id k8mr24660150ote.3.1512681119642; Thu, 07 Dec 2017 13:11:59 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 7 Dec 2017 13:11:59 -0800 From: Alvaro Retana X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Thu, 7 Dec 2017 13:11:59 -0800 Message-ID: To: draft-ietf-idr-bgp-gr-notification@ietf.org Cc: idr-chairs@ietf.org, idr@ietf.org, Jie Dong Content-Type: multipart/alternative; boundary="001a11c01f18cb79b6055fc6840c" Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-bgp-gr-notification-13 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Dec 2017 21:12:03 -0000 --001a11c01f18cb79b6055fc6840c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reading this document =E2=80=94 I have some comments, pleas= e see the list below. I understand the intent of this document: instead of resetting a BGP session when a NOTIFICATION is received, use Graceful Restart; if the session is going to *really* be reset, then use the new Hard Reset sub-code. That makes sense to me=E2=80=A6but, is that the only code/sub-co= de for which it makes sense to do a hard reset? The NOTIFICATION has always had the =E2=80=9Cstigma=E2=80=9D of being something bad, so much that we (idr/I= ETF) have even worked on ways to reduce its use (rfc7606, for example). I want to ask the WG to consider whether other code/sub-code NOTIFICATION combinations should also result in a hard reset. I think there are several cases, for example: (1) rfc4486 (Subcodes for BGP Cease Notification Message) defines =E2=80=9CAdministrative Shutdown=E2=80=9D ("a BGP speaker decides t= o administratively shut down its peering with a neighbor=E2=80=9D). It seems= to me that the sender of this NOTIFICATION would not want to "follow the rules for the Receiving Speaker=E2=80=9D (as specified in Section 4). (2) rfc4486 also defines "Administrative Reset=E2=80=9D ("a BGP speaker dec= ides to administratively reset the peering with a neighbor=E2=80=9D); no more detai= ls are provided, but that sounds like a hard reset to me. (3) =E2=80=A6there=E2=80=99s probably others... Having said all that, I note that Section 3.1. (Sending a Hard Reset) specifies the =E2=80=9Cencapsulation=E2=80=9D (for lack of a better word) o= f the real reason for the Hard Reset. If the consensus is to go forward with that, and not call out other exceptions, then I think that the text in 3.1 should expand more on the encapsulation operation and the rationale for doing it this way, and the document should also address other recent work that recommends the use of Administrative Shutdown, for example draft-ietf-grow-bgp-session-culling (a BCP currently in the RFC Editor=E2= =80=99s Queue). [After I wrote the text above=E2=80=A6] I found that some of the points hav= e been discussed on the list already =E2=80=94 please include some of that discussion/analysis in the document. I=E2=80=99ll wait until the issue above and ones marked Major (below) are a= ddressed before starting the IETF LC. Thanks! Alvaro. Major: M1. Unfortunately, rfc4724 failed to setup a registry for the Restat Flags (or the Flags for Address Family), which means that anyone is able to use the bits in there (assuming the receiver looks at them, of course). Given that there are only a few bits, and to prevent conflicts, I would really like to see a registry set up. This document is already tagged to Update rfc4724, so it seems like a good place to establish the registries. [If for some reason you rather not include that information here, then we can take care of it elsewhere. IOW, this request is not a requirement.] M2. Section 4.1. (Rules for the Receiving Speaker) has me a little confused. Are the proposed changes contingent to setting the N bit? The text starts by saying: "As part of this extension, routes from the peer previously marked as stale MUST NOT be deleted, until and unless the optional timer=E2=80=A6expires=E2=80=A6=E2=80=9D=E2=80=A6does that mean= that the timer is no longer optional? Then you also say: =E2=80=9C...if the Graceful Notificat= ion ("N") bit is not set in the newly received Graceful Restart Capability, no new actions are triggered on the Receiving Speaker -- in particular, a clear "N=E2=80=9D bit does not trigger deletion of stale routes.=E2=80=9D If I understand rfc4724 correctly, stale routes could be deleted =E2=80=94 the text indicates changes in the behavior even if the N = bit is not set, right? If you are Updating this section of rfc4724, what would make it crystal clear is an =E2=80=9COLD/NEW=E2=80=9D notation of the= text (as in, this is the OLD text=E2=80=A6and this is the NEW text=E2=80=A6). M3. Security Considerations: Maybe not a security issue, but something to think about. Section 4.1 says that =E2=80=9Croutes...previous= ly marked as stale MUST NOT be deleted, until and unless the optional timer...expires, or unless a Hard Reset is performed. This supersedes the =E2=80=9Cconsecutive restarts=E2=80=9D requirement=E2=80=A6=E2=80=9D. = Not deleting the stale routes and not making the timer mandatory could result in stale routes that live forever if an attacker manages to create consecutive restarts (by simply sending NOTIFICATIONS before EoR) =E2=80=94 stale route= s are ok in the short term, but may point in the wrong direction eventually. Is this an issue? I think that it would be mitigated if the timer was made mandatory (with a nice default). Minor: P1. Section 4: =E2=80=9C...receive and send BGP NOTIFICATION messages in Graceful mode...=E2=80=9D What is =E2=80=9CGraceful mode=E2=80=9D? Nits: N1. In Section 2, please indicate that the first figure corresponds to the GR Capability from rfc4724. N2. s/subcode is defined known as/subcode is defined as N3. s/Graceful Notification flag/Graceful Notification bit (For consistency) N4. The operation is obviously per-AF; maybe it=E2=80=99s worth saying that somewhere just for completeness. --001a11c01f18cb79b6055fc6840c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear authors:

I just finished reading t= his document=C2=A0=E2=80=94 I have=C2=A0some comments, please see the list = below.

I understand the intent of this document: instead of r= esetting a BGP session when a NOTIFICATION is received, use Graceful Restar= t; if the session is going to *really* be reset, then use the new Hard Rese= t sub-code.=C2=A0 That makes sense to me=E2=80=A6but, is that the only code= /sub-code for which it makes sense to do a hard reset?=C2=A0 The NOTIFICATI= ON has always had the=C2=A0=E2=80=9Cstigma=E2=80=9D of being something bad,= so much that we (idr/IETF) have even worked on ways to reduce its use (rfc= 7606, for example).=C2=A0 I want to ask the WG to consider whether other co= de/sub-code NOTIFICATION combinations should also result in a hard reset.= =C2=A0 I think there are several cases, for example:

(1)=C2= =A0rfc4486 (Subcodes for BGP Cease Notification Message) defines=C2=A0=E2= =80=9CAdministrative Shutdown=E2=80=9D ("a BGP speaker decides to admi= nistratively shut down its peering with a neighbor=E2=80=9D).=C2=A0 It seem= s to me that the sender of this NOTIFICATION would not want to "follow= the rules for the Receiving Speaker=E2=80=9D (as specified in Section 4).<= /font>

(2) rfc4486 also defines "Administrative Reset=E2=80=9D= ("a BGP speaker decides to administratively reset the peering = with a neighbor=E2=80=9D); no more details are provided, but that sounds li= ke a hard reset to me.

(3) =E2=80=A6there=E2=80=99= s probably others...

Having said all that, I note = that Section=C2=A03.1. (Sending a Hard Reset) specifies the =E2=80=9Cencaps= ulation=E2=80=9D (for lack of a better word) of the real reason for the Har= d Reset.=C2=A0 If the consensus is to go forward with that, and not call ou= t other exceptions, then I think that the text in 3.1 should expand more on= the encapsulation operation and the rationale for doing it this way, and t= he document should also address other recent work that recommends the use o= f Administrative Shutdown, for example draft-ietf-grow-bgp-session-culling = (a BCP currently in the RFC Editor=E2=80=99s Queue).

[After I wrote the text above=E2=80=A6] I found that some of the points = have been discussed on the list already =E2=80=94 please include some of th= at discussion/analysis in the document.


=
I=E2=80=99ll wait until the issue above and ones marked Major (below) = are addressed before starting the IETF LC.

Thanks!=

Alvaro.


<= br>
Major:

M1. Unfortunately, rfc4724 failed to setup a = registry for the Restat Flags (or the Flags for Address Family), which means that anyone is able to use the bits in there (assuming the receiver looks at them, of course).=C2=A0 Given that there are only a few bits, and to prevent conflicts, I would really like to see a registry set up.=C2=A0 This document is already tagged to Update rfc4724, so it seems like a good place to establish the registries. =C2=A0[If for some reason you rather not include that information here, then we can take care of it elsewhere.=C2=A0 IOW, this request is not a requirement.]

M2. Se=
ction 4.1. (Rules for the Receiving Speaker) has me a little confused.  Are=
 the proposed changes contingent to setting the N bit?  The text starts by =
saying: "As part of this =
extension, routes from the peer previously marked as stale MUST NOT be deleted, until and unless the opti=
onal timer=E2=80=A6expires=E2=80=A6=E2=80=
=9D=E2=80=A6does that mean that the timer is no longer optional?   Then you=
 also say: =E2=80=9C...if the =
Graceful Notification ("N") bit is not set in the newly received Graceful Restart Capability, n=
o new actions are triggered on the Receivin=
g Speaker -- in particular, a clear "N=E2=80=9D bit does not trigger d=
eletion of stale routes.=E2=80=9D  If I understand rfc4724 correctly, stale=
 routes could be deleted =E2=80=94 the text indicates changes in the behavi=
or even if the N bit is not set, right?  If you are Updating this section o=
f rfc4724, what would make it crystal clear is an =E2=80=9COLD/NEW=E2=80=9D=
 notation of the text (as in, this is the OLD text=E2=80=A6and this is the =
NEW text=E2=80=A6).


M3. Security Considerations:  Maybe =
not a security issue, but something to think about.  Section 4.1 says that =
=E2=80=9Croutes...previously marked as stale MUST NOT be deleted, until and=
 unless the optional timer...expires, or unless a Hard Reset is performed. =
 This supersedes the =E2=80=9Cconsecutive restarts=E2=80=9D requirement=E2=
=80=A6=E2=80=9D.  Not deleting the stale routes and not making the timer ma=
ndatory could result in stale routes that live forever if an attacker manag=
es to create consecutive restarts (by simply sending NOTIFICATIONS before E=
oR) =E2=80=94 stale routes are ok in the short term, but may point in the w=
rong direction eventually.  Is this an issue?  I think that it would be mit=
igated if the timer was made mandatory (with a nice default).
<= pre class=3D"newpage" style=3D"margin-top:0px;margin-bottom:0px">
=


Minor:

P1. Secti=
on 4: =E2=80=9C...receive and send BGP NOTIFICATION <=
span style=3D"font-family:Helvetica">messages in Graceful mode...=E2=80=9D =
What is =E2=80=9CGraceful mode=E2=80=9D?



Nits:

N1. In Section 2, please indicate that the fi= rst figure corresponds to the GR Capability from rfc4724.

N2. s/subcode is defined known as/subcode is defined as

N3. s/Graceful Notification flag/Graceful Not= ification bit =C2=A0 (For consistency)

N4. The operation is obviously per-AF; maybe it= =E2=80=99s worth saying that somewhere just for completeness.
--001a11c01f18cb79b6055fc6840c-- From nobody Fri Dec 8 07:47:42 2017 Return-Path: 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 4D73B126B6D for ; Fri, 8 Dec 2017 07:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, UNPARSEABLE_RELAY=0.001] autolearn=no 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 MUVt3w9ut79D for ; Fri, 8 Dec 2017 07:47:37 -0800 (PST) Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (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 384331243F6 for ; Fri, 8 Dec 2017 07:47:37 -0800 (PST) Received: by mail-lf0-f42.google.com with SMTP id 74so12347193lfs.0 for ; Fri, 08 Dec 2017 07:47:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=9FTacRVetZhcVP1SbXzfLsANVxBhlpHYMWPBt65WI9U=; b=t75YfT+PtWN0jsLXc17IvFX2HMZUE9L0lKRS20lKJrNKO9E/lZIkywRAxkKK2aABgC FUS78fAWd6bqEivLFhLZpLUJYgC2srd0MzVqDcqtCR1T7p4CT0ie/u92PP0CdAbmfKYn /ylWHmpjkNwG3ZJYUXTSc3wPRRYW+Aoz7v4PmJtGMbC6ZkmJHI+dc1vxmJpmKDAmcCQB BIotLLnjqu+wpsBhQ7Weorbdi5FJiJrQCNBPAWAS+nfxjqj7hE697AHVN2a1s/y0XXN7 UZOGAHvTEJOoZxxk4yVX2QuWWcXDCQXqJS99TzIChmy1XGD734GkF1QYIek/pu7U/4Sd B/mQ== X-Gm-Message-State: AJaThX6+Fzai4lPfCVqqnEazjlJM08CQP4NAwg0nBv7y08kPBDtWL3r7 sRrfgU2Khue0/DZMWgqNjt2wxVRXpxQ= X-Google-Smtp-Source: AGs4zMYei6gvxT9zz9PfYGRHqDz3f04YSkY/h5ucUdk53j6YHZ+bsDibhnbcQgDkwZDMicjfmWuMwQ== X-Received: by 10.46.17.70 with SMTP id f67mr15873539lje.160.1512748055065; Fri, 08 Dec 2017 07:47:35 -0800 (PST) Received: from vurt.meerval.net ([95.143.124.62]) by smtp.gmail.com with ESMTPSA id u27sm1489862ljd.70.2017.12.08.07.47.33 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Dec 2017 07:47:34 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 3e05f48c; Fri, 8 Dec 2017 15:47:35 +0000 (UTC) Date: Fri, 8 Dec 2017 15:47:35 +0000 From: Job Snijders To: idr@ietf.org Message-ID: <20171208154735.GH61799@vurt.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 15:47:39 -0000 Dear IDR, So, it appears I was wrong to push for the arbitrary maximum length of 128 octets when we worked on the BGP Administrative Shutdown Communication (RFC 8203). At the time, multiple people pointed out that it might be better to let the the thing be a little bit longer (255), and in retrospect that indeed would've been better. I'm sorry :( At this month's peering forum meeting of the Moscow Internet Exchange, Misha Grishin (MSK-IX) reported on experiences with the shutdown communication, and indicated that the concept was considered useful, but that 128 octets is too small in context of multibyte character sets such as Cyrillic script and they couldn't easily fit the short messages they wanted to send in the communication. The GoBGP authors also questioned the 128 limit during the implementation phase, I now see why. Operational feedback like this is invaluable and worth our consideration. I think that allowing all possible values in the shutdown communication length field will allow more societies to use the shutdown communication feature in their native script, and this outweights the additional risk of visual spoofing that an additional 127 octets could bring. I think it won't be too hard to update the existing implementations. We've posted a short draft to update use of the length field in rfc8203. Thoughts? Kind regards, Job ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 08 Dec 2017 07:22:57 -0800 From: internet-drafts@ietf.org To: Job Snijders , Alexander Azimov Subject: New Version Notification for draft-snijders-idr-rfc8203bis-00.txt A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt has been successfully submitted by Job Snijders and posted to the IETF repository. Name: draft-snijders-idr-rfc8203bis Revision: 00 Title: Extended BGP Administrative Shutdown Communication Document date: 2017-12-07 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-snijders-idr-rfc8203bis-00.txt Status: https://datatracker.ietf.org/doc/draft-snijders-idr-rfc8203bis/ Htmlized: https://tools.ietf.org/html/draft-snijders-idr-rfc8203bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-snijders-idr-rfc8203bis-00 Abstract: This document updates RFC8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. 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. The IETF Secretariat ----- End forwarded message ----- From nobody Fri Dec 8 09:10:13 2017 Return-Path: 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 A5A18127522 for ; Fri, 8 Dec 2017 09:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 WACwnvQAqG6v for ; Fri, 8 Dec 2017 09:10:10 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 419E8126DFB for ; Fri, 8 Dec 2017 09:10:10 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: Date: Fri, 8 Dec 2017 12:10:03 -0500 Message-ID: <014101d37047$63eef530$2bccdf90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01D3701D.7B18ED30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdNwR0Ep3YRSQoYwSe+55gJblUBfMA== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:10:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0142_01D3701D.7B18ED30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a week WG call for approval of early code point allocation for draft-ietf-eag-distribution-05.txt. You can view the specification at: https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/ The specification has gone through 5 revisions. There are two organizations interested in implementing this specification. Please send in your comments by 12/22. Susan Hares ------=_NextPart_000_0142_01D3701D.7B18ED30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a  week WG call for approval of early code point allocation = for draft-ietf-eag-distribution-05.txt. 

You can view the specification at:

https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/

 

The specification has gone through 5 revisions.  = There are two organizations interested in implementing this = specification.   Please send in your comments by 12/22.  =

 

Susan Hares

------=_NextPart_000_0142_01D3701D.7B18ED30-- From nobody Fri Dec 8 09:35:13 2017 Return-Path: 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 22F71127077 for ; Fri, 8 Dec 2017 09:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 ep-Ri0jYo77X for ; Fri, 8 Dec 2017 09:35:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F57120713 for ; Fri, 8 Dec 2017 09:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6847; q=dns/txt; s=iport; t=1512754510; x=1513964110; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Z8sUJqOmdO4nN1N/Z0uezcT4uybU9wPHtro56Fy1MBs=; b=LvtJN9mOgd4giAohpnnGgA6rH/7kBe/d+6B49SIzU+qtEVt1nEsR7EY5 GZ7clgs8Y2hd9qM7AbNdG4ZAkA3rU61A2I68G7VBTMJ61xFh7XAZ6+JTG +pU9iU6pQW/+ApVAOEdBzpgAUlu0fZ2pjKO+g4zUpNpUt65c7y1Yi7n8i I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzCwB4zCpa/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweDe4ohjmIBHYF9gVqPZ4VLghUKI4UYAhqERT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQEDHQYKXAIBCA4DAwECKAMCAgIwFAkIAQEEARKJRGQQq?= =?us-ascii?q?B2CJ4pjAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDW4FhASmGNDaDMoINgnWCYwW?= =?us-ascii?q?jCAKHd40nghaGEos5jQiJJwIRGQGBOgEfOYFPbxU6gimDB4FOeIkhgRUBAQE?= X-IronPort-AV: E=Sophos; i="5.45,378,1508803200"; d="scan'208,217"; a="41588216" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 17:35:09 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB8HZ9Fn011592 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 17:35:09 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 12:35:08 -0500 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; Fri, 8 Dec 2017 12:35:08 -0500 From: "Acee Lindem (acee)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) Thread-Index: AdNwR0Ep3YRSQoYwSe+55gJblUBfMAAA6CEA Date: Fri, 8 Dec 2017 17:35:08 +0000 Message-ID: References: <014101d37047$63eef530$2bccdf90$@ndzh.com> In-Reply-To: <014101d37047$63eef530$2bccdf90$@ndzh.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.198] Content-Type: multipart/alternative; boundary="_000_D6503705E0A23aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:35:12 -0000 --_000_D6503705E0A23aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpJIHN1cHBvcnQgZWFybHkgYWxsb2NhdGlvbi4gSW4gZmFjdCwgZm9yIFdHIGRv Y3VtZW50cyBJIHRoaW5rIHdlIHNob3VsZG7igJl0IHBsYWNlIHN1Y2ggYSBoaWdoIGJhciBvbiBl YXJseSBhbGxvY2F0aW9uLg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IElkciA8aWRyLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFN1 c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpEYXRl OiBGcmlkYXksIERlY2VtYmVyIDgsIDIwMTcgYXQgMTI6MTAgUE0NClRvOiBJRFIgTGlzdCA8aWRy QGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gRWFybHkgQ29k ZSBQb2ludCBhbGxvY2F0aW9uIGZvciBkcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTA1 ICgxMi84IHRvIDEyLzIyKQ0KDQpUaGlzIGJlZ2lucyBhICB3ZWVrIFdHIGNhbGwgZm9yIGFwcHJv dmFsIG9mIGVhcmx5IGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1lYWctZGlz dHJpYnV0aW9uLTA1LnR4dC4NCllvdSBjYW4gdmlldyB0aGUgc3BlY2lmaWNhdGlvbiBhdDoNCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmli dXRpb24vDQoNClRoZSBzcGVjaWZpY2F0aW9uIGhhcyBnb25lIHRocm91Z2ggNSByZXZpc2lvbnMu ICBUaGVyZSBhcmUgdHdvIG9yZ2FuaXphdGlvbnMgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcg dGhpcyBzcGVjaWZpY2F0aW9uLiAgIFBsZWFzZSBzZW5kIGluIHlvdXIgY29tbWVudHMgYnkgMTIv MjIuDQoNClN1c2FuIEhhcmVzDQo= --_000_D6503705E0A23aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBTdWUsJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIHN1cHBvcnQgZWFybHkgYWxsb2Nh dGlvbi4gSW4gZmFjdCwgZm9yIFdHIGRvY3VtZW50cyBJIHRoaW5rIHdlIHNob3VsZG7igJl0IHBs YWNlIHN1Y2ggYSBoaWdoIGJhciBvbiBlYXJseSBhbGxvY2F0aW9uLiZuYnNwOzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWdu OmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxF RlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsg UEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVS LVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPklkciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkci1i b3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVz QG5kemguY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0 ZTogPC9zcGFuPkZyaWRheSwgRGVjZW1iZXIgOCwgMjAxNyBhdCAxMjoxMCBQTTxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPklEUiBMaXN0ICZsdDs8YSBocmVm PSJtYWlsdG86aWRyQGlldGYub3JnIj5pZHJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+W0lkcl0gRWFybHkgQ29kZSBQ b2ludCBhbGxvY2F0aW9uIGZvciBkcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTA1ICgx Mi84IHRvIDEyLzIyKTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxF RlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0K PGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNy b3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9U Ui9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0 IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5p dGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgYmVnaW5zIGEmbmJzcDsgd2Vl ayBXRyBjYWxsIGZvciBhcHByb3ZhbCBvZiBlYXJseSBjb2RlIHBvaW50IGFsbG9jYXRpb24gZm9y IGRyYWZ0LWlldGYtZWFnLWRpc3RyaWJ1dGlvbi0wNS50eHQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4gdmlldyB0aGUgc3BlY2lmaWNhdGlvbiBh dDogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9u LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItZWFnLWRp c3RyaWJ1dGlvbi88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzcGVjaWZpY2F0aW9u IGhhcyBnb25lIHRocm91Z2ggNSByZXZpc2lvbnMuJm5ic3A7IFRoZXJlIGFyZSB0d28gb3JnYW5p emF0aW9ucyBpbnRlcmVzdGVkIGluIGltcGxlbWVudGluZyB0aGlzIHNwZWNpZmljYXRpb24uJm5i c3A7Jm5ic3A7IFBsZWFzZSBzZW5kIGluIHlvdXIgY29tbWVudHMgYnkgMTIvMjIuJm5ic3A7DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VzYW4gSGFyZXMgPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D6503705E0A23aceeciscocom_-- From nobody Fri Dec 8 09:50:30 2017 Return-Path: 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 80B0212778D for ; Fri, 8 Dec 2017 09:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 DC6Gbdo89BOW for ; Fri, 8 Dec 2017 09:50:25 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1361274D2 for ; Fri, 8 Dec 2017 09:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10710; q=dns/txt; s=iport; t=1512755425; x=1513965025; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kWAbFypcwXw1QgbcSfbGHygUTZcya6FCnchjR+YfL10=; b=K4pMEsaiOFWl0SmDBEWLidMrf9EN9Hq6WXPrNTyVNHGsMOUxb+MHjzrD NXMPQsrseEGyU9bjBWocfZLLdjCg7w+8B7rjavuredgwoz2MZ7tvn2yTf 4zfP5hyp63hNnnPpTU6QRdCq6ksAH9sKscUFAPJu8o0Gi66rbAd2ehcjZ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzCwB40Cpa/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweDe4ohjmIBHYF9gVqPZ4VLghUKI4UYAhqERT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQEDHQYKXAIBCBEDAQEBKAMCAgIwFAkIAQEEARIIiTxkE?= =?us-ascii?q?KglgieKYwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg1uBYQEpgVaEXjaDMoINFoJ?= =?us-ascii?q?fgmMFikyYPAKHd40egh+BfYQVizmNCIknAhEZAYE6AR85gU9vFTqCKYMHgU54i?= =?us-ascii?q?SGBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208,217";a="330126826" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 17:50:24 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB8HoNdb028075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 17:50:23 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 8 Dec 2017 11:50:23 -0600 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.1320.000; Fri, 8 Dec 2017 11:50:22 -0600 From: "Ketan Talaulikar (ketant)" To: "Acee Lindem (acee)" , Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) Thread-Index: AdNwR0Ep3YRSQoYwSe+55gJblUBfMAAA6CEAAABw6NA= Date: Fri, 8 Dec 2017 17:50:22 +0000 Message-ID: <4b4cfe4b0f6048f1bd47d4eaba653b10@XCH-ALN-008.cisco.com> References: <014101d37047$63eef530$2bccdf90$@ndzh.com> In-Reply-To: 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.32.67] Content-Type: multipart/alternative; boundary="_000_4b4cfe4b0f6048f1bd47d4eaba653b10XCHALN008ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 17:50:28 -0000 --_000_4b4cfe4b0f6048f1bd47d4eaba653b10XCHALN008ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgc3VwcG9ydCBlYXJseSBhbGxvY2F0aW9uLiBJIGFsc28gYmVsaWV2ZSB0aGUg ZHJhZnQgaXMgZmFpcmx5IG1hdHVyZSBhbmQgc3RhYmxlIGZvciBpbXBsZW1lbnRhdGlvbiBvbmNl IHRoZSBjb2RlIHBvaW50cyBhcmUgYXZhaWxhYmxlLg0KDQpUaGFua3MsDQpLZXRhbg0KDQpGcm9t OiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGlu ZGVtIChhY2VlKQ0KU2VudDogMDggRGVjZW1iZXIgMjAxNyAyMzowNQ0KVG86IFN1c2FuIEhhcmVz IDxzaGFyZXNAbmR6aC5jb20+OyBpZHJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWRyXSBFYXJs eSBDb2RlIFBvaW50IGFsbG9jYXRpb24gZm9yIGRyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRp b24tMDUgKDEyLzggdG8gMTIvMjIpDQoNCkhpIFN1ZSwNCg0KSSBzdXBwb3J0IGVhcmx5IGFsbG9j YXRpb24uIEluIGZhY3QsIGZvciBXRyBkb2N1bWVudHMgSSB0aGluayB3ZSBzaG91bGRu4oCZdCBw bGFjZSBzdWNoIGEgaGlnaCBiYXIgb24gZWFybHkgYWxsb2NhdGlvbi4NCg0KVGhhbmtzLA0KQWNl ZQ0KDQpGcm9tOiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppZHItYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyA8c2hhcmVzQG5kemguY29tPG1haWx0 bzpzaGFyZXNAbmR6aC5jb20+Pg0KRGF0ZTogRnJpZGF5LCBEZWNlbWJlciA4LCAyMDE3IGF0IDEy OjEwIFBNDQpUbzogSURSIExpc3QgPGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPj4N ClN1YmplY3Q6IFtJZHJdIEVhcmx5IENvZGUgUG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0 Zi1pZHItZWFnLWRpc3RyaWJ1dGlvbi0wNSAoMTIvOCB0byAxMi8yMikNCg0KVGhpcyBiZWdpbnMg YSAgd2VlayBXRyBjYWxsIGZvciBhcHByb3ZhbCBvZiBlYXJseSBjb2RlIHBvaW50IGFsbG9jYXRp b24gZm9yIGRyYWZ0LWlldGYtZWFnLWRpc3RyaWJ1dGlvbi0wNS50eHQuDQpZb3UgY2FuIHZpZXcg dGhlIHNwZWNpZmljYXRpb24gYXQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLw0KDQpUaGUgc3BlY2lmaWNhdGlvbiBoYXMg Z29uZSB0aHJvdWdoIDUgcmV2aXNpb25zLiAgVGhlcmUgYXJlIHR3byBvcmdhbml6YXRpb25zIGlu dGVyZXN0ZWQgaW4gaW1wbGVtZW50aW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4gICBQbGVhc2Ugc2Vu ZCBpbiB5b3VyIGNvbW1lbnRzIGJ5IDEyLzIyLg0KDQpTdXNhbiBIYXJlcw0K --_000_4b4cfe4b0f6048f1bd47d4eaba653b10XCHALN008ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tSU4iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IZWxsbyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc3VwcG9ydCBlYXJseSBhbGxvY2F0aW9uLiBJIGFsc28gYmVs aWV2ZSB0aGUgZHJhZnQgaXMgZmFpcmx5IG1hdHVyZSBhbmQgc3RhYmxlIGZvciBpbXBsZW1lbnRh dGlvbiBvbmNlIHRoZSBjb2RlIHBvaW50cyBhcmUgYXZhaWxhYmxlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5LZXRhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IElkciBbbWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BY2VlIExpbmRlbSAoYWNlZSk8YnI+DQo8Yj5T ZW50OjwvYj4gMDggRGVjZW1iZXIgMjAxNyAyMzowNTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFy ZXMgJmx0O3NoYXJlc0BuZHpoLmNvbSZndDs7IGlkckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW0lkcl0gRWFybHkgQ29kZSBQb2ludCBhbGxvY2F0aW9uIGZvciBkcmFmdC1pZXRm LWlkci1lYWctZGlzdHJpYnV0aW9uLTA1ICgxMi84IHRvIDEyLzIyKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+SGkgU3VlLCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+SSBzdXBwb3J0IGVhcmx5IGFsbG9jYXRpb24uIEluIGZhY3Qs IGZvciBXRyBkb2N1bWVudHMgSSB0aGluayB3ZSBzaG91bGRu4oCZdCBwbGFjZSBzdWNoIGEgaGln aCBiYXIgb24gZWFybHkgYWxsb2NhdGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+QWNlZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklk ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnIj5pZHItYm91bmNlc0Bp ZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+RnJpZGF5LCBEZWNlbWJlciA4LCAyMDE3IGF0IDEyOjEwIFBNPGJyPg0KPGI+VG86IDwv Yj5JRFIgTGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlkckBpZXRmLm9yZyI+aWRyQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0lkcl0gRWFybHkgQ29kZSBQb2ludCBhbGxv Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTA1ICgxMi84IHRvIDEy LzIyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi1yaWdodDowY20iIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBiZWdpbnMg YSZuYnNwOyB3ZWVrIFdHIGNhbGwgZm9yIGFwcHJvdmFsIG9mIGVhcmx5IGNvZGUgcG9pbnQgYWxs b2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1lYWctZGlzdHJpYnV0aW9uLTA1LnR4dC4mbmJzcDsNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPllvdSBjYW4gdmlldyB0aGUgc3BlY2lmaWNhdGlvbiBh dDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRpb24vIj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9u LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OmJsYWNrIj5UaGUgc3BlY2lmaWNhdGlvbiBoYXMgZ29uZSB0aHJvdWdoIDUgcmV2aXNpb25zLiZu YnNwOyBUaGVyZSBhcmUgdHdvIG9yZ2FuaXphdGlvbnMgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRp bmcgdGhpcyBzcGVjaWZpY2F0aW9uLiZuYnNwOyZuYnNwOyBQbGVhc2Ugc2VuZCBpbiB5b3VyIGNv bW1lbnRzIGJ5IDEyLzIyLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+U3VzYW4gSGFyZXMgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_4b4cfe4b0f6048f1bd47d4eaba653b10XCHALN008ciscocom_-- From nobody Fri Dec 8 10:52:26 2017 Return-Path: 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 D0D7B1275FD for ; Fri, 8 Dec 2017 10:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 tS00Obr-EYHv for ; Fri, 8 Dec 2017 10:52:24 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 EC9B01275F4 for ; Fri, 8 Dec 2017 10:52:23 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Acee Lindem \(acee\)'" , References: <014101d37047$63eef530$2bccdf90$@ndzh.com> In-Reply-To: Date: Fri, 8 Dec 2017 13:52:20 -0500 Message-ID: <005501d37055$adbbbf50$09333df0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01D3702B.C4E5B750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDYshkkKYTnkh1nQg/jwqNWSFF6FgE1Dd1UpSWeBrA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 18:52:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01D3702B.C4E5B750 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Acee: =20 I agree with your viewpoint. IDR and ISIS/OSPF are very thoughtful = about the drafts they adopt. The IDR WG has clearly stated they want = allocations done whenever possible. However, I have gotten push-back = from this IESG. So, I=E2=80=99ve made this call to the WG.=20 =20 Sue Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Friday, December 8, 2017 12:35 PM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] Early Code Point allocation for = draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) =20 Hi Sue,=20 =20 I support early allocation. In fact, for WG documents I think we = shouldn=E2=80=99t place such a high bar on early allocation.=20 =20 Thanks, Acee=20 =20 From: Idr on behalf of Susan Hares = Date: Friday, December 8, 2017 at 12:10 PM To: IDR List Subject: [Idr] Early Code Point allocation for = draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) =20 This begins a week WG call for approval of early code point allocation = for draft-ietf-eag-distribution-05.txt. =20 You can view the specification at:=20 https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/ =20 The specification has gone through 5 revisions. There are two = organizations interested in implementing this specification. Please = send in your comments by 12/22. =20 =20 Susan Hares=20 ------=_NextPart_000_0056_01D3702B.C4E5B750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Acee:

 

I agree with your = viewpoint. =C2=A0=C2=A0IDR and ISIS/OSPF are very thoughtful about the = drafts they adopt. =C2=A0The IDR WG has clearly stated they want = allocations done whenever possible. However, I have gotten push-back = from this IESG. =C2=A0=C2=A0So, I=E2=80=99ve made this call to the WG. =

 

Sue Hares =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Acee Lindem = (acee)
Sent: Friday, December 8, 2017 12:35 PM
To: = Susan Hares; idr@ietf.org
Subject: Re: [Idr] Early Code Point = allocation for draft-ietf-idr-eag-distribution-05 (12/8 to = 12/22)

 

Hi = Sue, 

 

=

I = support early allocation. In fact, for WG documents I think we = shouldn=E2=80=99t place such a high bar on early = allocation. 

 

=

Thanks,

Acee 

 

=

From: = Idr <idr-bounces@ietf.org> on = behalf of Susan Hares <shares@ndzh.com>
Date: = Friday, December 8, 2017 at 12:10 PM
To: IDR List <idr@ietf.org>
Subject: = [Idr] Early Code Point allocation for = draft-ietf-idr-eag-distribution-05 (12/8 to = 12/22)

 

=

This begins a  week = WG call for approval of early code point allocation for = draft-ietf-eag-distribution-05.txt. 

You can view the = specification at:

https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/

 

The specification has gone = through 5 revisions.  There are two organizations interested in = implementing this specification.   Please send in your = comments by 12/22. 

 

Susan Hares =

------=_NextPart_000_0056_01D3702B.C4E5B750-- From nobody Fri Dec 8 12:12:21 2017 Return-Path: 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 EC50F128BB7 for ; Fri, 8 Dec 2017 12:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNWor_FvET2h for ; Fri, 8 Dec 2017 12:12:12 -0800 (PST) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id D5BBD126D3F for ; Fri, 8 Dec 2017 12:12:12 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id F0ADF54067F; Fri, 8 Dec 2017 15:12:10 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Jared Mauch In-Reply-To: <20171208154735.GH61799@vurt.meerval.net> Date: Fri, 8 Dec 2017 15:12:04 -0500 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> References: <20171208154735.GH61799@vurt.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 20:12:18 -0000 Job, > On Dec 8, 2017, at 10:47 AM, Job Snijders wrote: >=20 > Dear IDR, >=20 > So, it appears I was wrong to push for the arbitrary maximum length of > 128 octets when we worked on the BGP Administrative Shutdown > Communication (RFC 8203). At the time, multiple people pointed out = that > it might be better to let the the thing be a little bit longer (255), > and in retrospect that indeed would've been better. I'm sorry :( >=20 > At this month's peering forum meeting of the Moscow Internet Exchange, > Misha Grishin (MSK-IX) reported on experiences with the shutdown > communication, and indicated that the concept was considered useful, = but > that 128 octets is too small in context of multibyte character sets = such > as Cyrillic script and they couldn't easily fit the short messages = they > wanted to send in the communication. The GoBGP authors also questioned > the 128 limit during the implementation phase, I now see why. > Operational feedback like this is invaluable and worth our > consideration. I support fixing this. Is 255 the right number? If all the chars are 4 byte that supports 63 = chars. I=E2=80=99m by no means a unicode expert, but if we fix it, we should = ensure the right number is used. - Jared ps - wanting to avoid future =F0=9F=92=A9= From nobody Fri Dec 8 15:08:15 2017 Return-Path: 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 4CC6C128BC8 for ; Fri, 8 Dec 2017 15:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=exa-net-uk.20150623.gappssmtp.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 xAWPmFaV86po for ; Fri, 8 Dec 2017 15:08:12 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 37F7912025C for ; Fri, 8 Dec 2017 15:08:12 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id x20so8171123oix.12 for ; Fri, 08 Dec 2017 15:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exa-net-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=iePLYKp/aAmDyQ8f7gJ1ll+0uluh5Sl5I5No2tAYsvo=; b=LONRYI6DZPBR6SzfKYsiGYvS3rvZ90DTqoMSlofzrGUhORSHjeKRr6SAXsq3kzUFjj E/8IAsQvaX6mvd07Cr0jCO53CTDp9SnKE1rOLowxv8RVcTI9Bc/1JZd3cTPK1hrKymO8 P+sa05MBl3XN8v72WKr2PP+DK+w5HHWYEJwJtLcqQ3uoG6IvkR+KM0ZvAiMoGcEqgRbZ 7BXIScPfy9+9cOtmfs4ZxbMVr+B8qWRR8RhmOMYYBubUNVMVqq3ow2MLUam5fW8gNNUw rrPwHO/sCwrihPVvAPZ6sOYkZVZ9ULfxFSRvERmJPLlKfZUTHT9RlBY7etzy+dmTDq4Q HGPA== 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; bh=iePLYKp/aAmDyQ8f7gJ1ll+0uluh5Sl5I5No2tAYsvo=; b=KYDNm5t/hxajV/4HLi32sfFx4l6OY12HHQPb7Fd/Rq0cMTTEk1KN5s37eFSmiJ4Vx5 TgfzRi1QfLd9AxLAX1Nmta8uwpcb+xB1aHCviqokcmu2+5ePoofdlHyrB6zKFG5jQovn 7UzYSLPml+CvFF7FPrHfxUJdvRsVcjfOoYtVyPBHxcQrXuazdROGMraCrisGzrMAneBN BunX7wdDbc6J264uJNAfaLxNe5Axv1SQAmaGDqHiPduJbayLXDmhSJ7jHhPqV+g1x3S4 IN0CFTB9YvTWo1J8VlQVJVSHljOG/zvDwjZXBN7HtbJHjFwPn875kTA5qm2p3sZHKMM6 a1mg== X-Gm-Message-State: AKGB3mIYwiGn6r9yFay27sC5jJJnS1c1OnxmzkkAO8tC4G0nBQul8C4N tZ6FIQXzu2zVfdgaHpptNp9sK3nhwt6nDSHQ9nkSP4CaEc0= X-Google-Smtp-Source: AGs4zMZNdFTL5VzKutUBSYMwA2xROcMJsDTRDJOsUcoaM0pIg/YhWew7vXnH5+A+CY0usBs5IdRPHDJVMJNwg2rI9vU= X-Received: by 10.202.221.193 with SMTP id u184mr7307664oig.121.1512774491320; Fri, 08 Dec 2017 15:08:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.86.178 with HTTP; Fri, 8 Dec 2017 15:07:55 -0800 (PST) In-Reply-To: <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> From: Thomas Mangin Date: Fri, 8 Dec 2017 23:07:55 +0000 Message-ID: To: idr@ietf.org Content-Type: multipart/alternative; boundary="001a113d3a842e46d4055fdc42f7" Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 23:08:14 -0000 --001a113d3a842e46d4055fdc42f7 Content-Type: text/plain; charset="UTF-8" Hello Job, I would support a reasonable increase 255 or more. Sincerely, Thomas --001a113d3a842e46d4055fdc42f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Job,

I would support a reasonab= le increase 255 or more.

Sincerely,

Thomas
--001a113d3a842e46d4055fdc42f7-- From nobody Sat Dec 9 12:26:11 2017 Return-Path: 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 F33FC127011 for ; Sat, 9 Dec 2017 12:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvZrId0QnN6W for ; Sat, 9 Dec 2017 12:26:08 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 BE2F5126579 for ; Sat, 9 Dec 2017 12:26:08 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eNlhG-0002v8-Pm; Sat, 09 Dec 2017 20:26:06 +0000 Date: Sat, 09 Dec 2017 12:26:06 -0800 Message-ID: From: Randy Bush To: Thomas Mangin Cc: idr@ietf.org In-Reply-To: References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2017 20:26:10 -0000 > I would support a reasonable increase 255 or more. 640 is a tempting classic choice From nobody Sat Dec 9 19:01:31 2017 Return-Path: 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 B02BC126D46 for ; Sat, 9 Dec 2017 19:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 zgxiLnjr4x2N for ; Sat, 9 Dec 2017 19:01:29 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 2B6B41200CF for ; Sat, 9 Dec 2017 19:01:29 -0800 (PST) Received: from [192.168.47.21] (c-73-189-177-254.hsd1.ca.comcast.net [73.189.177.254]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id vBA31LTd059209; Sun, 10 Dec 2017 03:01:22 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-189-177-254.hsd1.ca.comcast.net [73.189.177.254] claimed to be [192.168.47.21] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (15B202) In-Reply-To: Date: Sat, 9 Dec 2017 19:01:15 -0800 Cc: Thomas Mangin , idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> To: Randy Bush Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 03:01:31 -0000 Sent from my iPhone On Dec 9, 2017, at 12:26, Randy Bush wrote: >> I would support a reasonable increase 255 or more. > > 640 is a tempting classic choice Should be enough for anyone. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From nobody Sat Dec 9 21:00:48 2017 Return-Path: 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 1BE561267BB; Sat, 9 Dec 2017 21:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWO3z_dU2b-M; Sat, 9 Dec 2017 21:00:44 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0097.outbound.protection.outlook.com [23.103.201.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC682124BAC; Sat, 9 Dec 2017 21:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JUYdSyYFr0tV2lRU2YYwbqMEkmfEWkYQBYCSV6XhLPA=; b=yPu+vxxG6MgE06DY9/l7Z4NnmdQXrFGuHUAXIfQGw8Jwpksbm17PkouKlWDsFnPov5gN2t4ZcNkQywQAv15iCdNxL/lMWlYQlvpSpenJ5F312X50+b64Jqz0p4GTztXtN+yNhtuluwfuMHnELTA/FHSNi1vrsRR0irLGeGIHWok= Received: from SN4PR0901MB2176.namprd09.prod.outlook.com (10.167.151.140) by SN4PR0901MB2173.namprd09.prod.outlook.com (10.167.151.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Sun, 10 Dec 2017 05:00:42 +0000 Received: from SN4PR0901MB2176.namprd09.prod.outlook.com ([fe80::ac98:ab82:caf4:687f]) by SN4PR0901MB2176.namprd09.prod.outlook.com ([fe80::ac98:ab82:caf4:687f%13]) with mapi id 15.20.0239.013; Sun, 10 Dec 2017 05:00:41 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "jhaas@pfrc.org" , Robert Raszuk CC: Jakob Heitz , IDR , "idr-ads@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" Thread-Topic: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26) Thread-Index: AQHTcW8A02AKvtSu3U2WOg/rYTmNmg== Date: Sun, 10 Dec 2017 05:00:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN4PR0901MB2173; 6:M+Clk5gIf+PtzJ9uwhHWd4r87VEpZ5bM2fF/pggDiW3L8LiABmax204p1Gd2U9QP/TFm8nCOwgRD0yUyuOAukTr4gFWtsSLpWVkh8Z8NretplIUCzPjgxvkg/OMOpMpr7yCvHaM2BtWd4NrDfzG0C4mTlyp1eHrMiT8XUhw51O9dZLAgrqUmytqkMUazBiF+XDP0UjMOod8OLYdWlJV0EADk/xzDI+u/MOvlU7j3jzHNNM3MxrtZMAJCcxCluelfVVEW8+Ydzxiq/XtWIvAIf7JycrxgpNbJJLzw+dxRNKQh0G9D/iMNpwaVQamLwAXHPOta0gQm5s8Zmzwh5Uel6ANApTWZ7IctOeFxcYt00FI=; 5:2RfFLA7+uv9TRHVx32xyNCQNGO2A6G9w5HB+d2V+RMG6EzZHx+00Db/a42khRb85vpkCd38jRlEIWSrqV2POaTKVTIsuWDhKqEsxA/9TMMHHGOZta2eqYi089UamIoU7en2TporO43ZJ6ouJsC2UC5ibf0JgVGnsYybNMBSaIEY=; 24:1X0VYVkvSKmIUpXiT5t85Y6HOtU9RZFwHlOphizBegdzlrmDL9ggBBcWVZnDC8ScGS1KTnHu0MlU4Rv6QwnmTaidUtwUxDc/ZlJc7LmDIIY=; 7:BHoai3Wx8X+n863J2vv03BbzTfa1XLAP8GRpTTwmXWYkHajhEQMczMlklwQ+Ig3ZEOQccQsVQLr8yI5U6f7KcwmhT/bSDNonQb0SvMOAzM39xkiv57a+gPti1JNP0FlUGVYLg5gs3jjohxCTuJHZd205a9dozdbK5JVZ9KS3cnTiU0oPxDEP4oO4WgSdW71QLlE7CXTNw+Y1Rb1R+o/EWxvaBxRWeInl92ixGERLuk9r3o942zecurmid6JlpTKO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2b76102d-bc10-4d8e-5719-08d53f8af6a4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(2017052603307); SRVR:SN4PR0901MB2173; x-ms-traffictypediagnostic: SN4PR0901MB2173: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:SN4PR0901MB2173; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN4PR0901MB2173; x-forefront-prvs: 05177D47DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(189003)(199004)(24454002)(478600001)(6116002)(81166006)(3660700001)(6246003)(106356001)(97736004)(15650500001)(54906003)(14454004)(6436002)(7696005)(5660300001)(105586002)(7736002)(316002)(8936002)(2501003)(6506006)(8676002)(3280700002)(229853002)(966005)(53936002)(4326008)(305945005)(68736007)(2900100001)(230783001)(86362001)(3846002)(66066001)(9686003)(6306002)(55016002)(74316002)(5250100002)(110136005)(99286004)(25786009)(81156014)(2906002)(102836003)(33656002)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0901MB2173; H:SN4PR0901MB2176.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 2b76102d-bc10-4d8e-5719-08d53f8af6a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2017 05:00:41.7232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0901MB2173 Archived-At: Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 05:00:47 -0000 Jeff wrote: >> bgpsec implementations are likely to deploy extended messages in tandem. Robert wrote: >Is this just your assumption or is this enforced in any IETF document ?=20 >This is important news no one earlier mentioned in this entire thread. It was estimated that the maximum BGPsec_PATH attribute size=20 is not expected to exceed 4KB in the foreseeable future. The details of the measurements and estimation are here: https://datatracker.ietf.org/meeting/98/materials/slides-98-sidrops-decoupl= ing-bgpsec-documents-and-extended-messages-draft/=20 The BGPsec specification (RFC 8205) simply states the following (Sec. 4.1, = p. 14):=20 =93All BGPsec UPDATE messages MUST conform to BGP's maximum message size.= =94 It does not require enforcing deployment of extended messages.=20 Any sense of urgency for deployment of extended messages would be driven by not BGPsec, but other applications of BGP that may rely on them in the near= future.=20 =20 Sriram From nobody Sat Dec 9 21:55:45 2017 Return-Path: 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 9EEC1126CF9 for ; Sat, 9 Dec 2017 21:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Q_vjtp1DT6mT for ; Sat, 9 Dec 2017 21:55:42 -0800 (PST) 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 5C5D0120454 for ; Sat, 9 Dec 2017 21:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13764; q=dns/txt; s=iport; t=1512885342; x=1514094942; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yt/1A0+GA1TSmnN85C42McPOIIFn1bdi4ZJ0ZgcQ4wY=; b=Q0eg/hq5h/froHCSqAa+7xtahWHZo2RFRibAaCeX8LZXnBQcW53H6S4N l1fi2NeiEjcG7YzJH0MJmY/n6QDzsGOfGBOoZmK81En06f6nA2H/hCUDg WNS5GrR036PLQ7Vab9LvMes43FDu1Yjlo+lrb4slU85AdRUsGeczLRLYW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CACFyyxa/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweDe4ohjl8BHYF9flyPZ4VLghUKI4UYAhqERT8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQEDHQYKXAIBCA4DAwEBASgDAgICMBQJCAEBBAESCIk8Z?= =?us-ascii?q?BCmbIInimMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNogWEBKYFWgWmCdTaDMoI?= =?us-ascii?q?NFoJfgmMFmUuJRgKHd40fgh+GEos7jQqJJwIRGQGBOgEfOYFPbxU6gimDB4FOe?= =?us-ascii?q?IhbgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,386,1508803200"; d="scan'208,217";a="328731445" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Dec 2017 05:55:40 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBA5te4V023097 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Dec 2017 05:55:41 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 9 Dec 2017 23:55:40 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Sat, 9 Dec 2017 23:55:40 -0600 From: "Jakob Heitz (jheitz)" To: Susan Hares , "Acee Lindem (acee)" , "idr@ietf.org" Thread-Topic: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) Thread-Index: AdNwR0Ep3YRSQoYwSe+55gJblUBfMAAA6CEAAA9FeAAAPOFTMA== Date: Sun, 10 Dec 2017 05:55:40 +0000 Message-ID: References: <014101d37047$63eef530$2bccdf90$@ndzh.com> <005501d37055$adbbbf50$09333df0$@ndzh.com> In-Reply-To: <005501d37055$adbbbf50$09333df0$@ndzh.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.24.119.62] Content-Type: multipart/alternative; boundary="_000_a6469f0d367c48e2a062276f6ca9a785XCHALN014ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 05:55:45 -0000 --_000_a6469f0d367c48e2a062276f6ca9a785XCHALN014ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0Lg0KDQpUaGFua3MsDQpKYWtvYg0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1c2FuIEhhcmVzDQpTZW50OiBGcmlkYXksIERl Y2VtYmVyIDgsIDIwMTcgMTA6NTIgQU0NClRvOiBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz Y28uY29tPjsgaWRyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lkcl0gRWFybHkgQ29kZSBQb2lu dCBhbGxvY2F0aW9uIGZvciBkcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLTA1ICgxMi84 IHRvIDEyLzIyKQ0KDQpBY2VlOg0KDQpJIGFncmVlIHdpdGggeW91ciB2aWV3cG9pbnQuICAgSURS IGFuZCBJU0lTL09TUEYgYXJlIHZlcnkgdGhvdWdodGZ1bCBhYm91dCB0aGUgZHJhZnRzIHRoZXkg YWRvcHQuICBUaGUgSURSIFdHIGhhcyBjbGVhcmx5IHN0YXRlZCB0aGV5IHdhbnQgYWxsb2NhdGlv bnMgZG9uZSB3aGVuZXZlciBwb3NzaWJsZS4gSG93ZXZlciwgSSBoYXZlIGdvdHRlbiBwdXNoLWJh Y2sgZnJvbSB0aGlzIElFU0cuICAgU28sIEnigJl2ZSBtYWRlIHRoaXMgY2FsbCB0byB0aGUgV0cu DQoNClN1ZSBIYXJlcw0KDQpGcm9tOiBJZHIgW21haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEFjZWUgTGluZGVtIChhY2VlKQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciA4 LCAyMDE3IDEyOjM1IFBNDQpUbzogU3VzYW4gSGFyZXM7IGlkckBpZXRmLm9yZzxtYWlsdG86aWRy QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtJZHJdIEVhcmx5IENvZGUgUG9pbnQgYWxsb2NhdGlv biBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3RyaWJ1dGlvbi0wNSAoMTIvOCB0byAxMi8yMikN Cg0KSGkgU3VlLA0KDQpJIHN1cHBvcnQgZWFybHkgYWxsb2NhdGlvbi4gSW4gZmFjdCwgZm9yIFdH IGRvY3VtZW50cyBJIHRoaW5rIHdlIHNob3VsZG7igJl0IHBsYWNlIHN1Y2ggYSBoaWdoIGJhciBv biBlYXJseSBhbGxvY2F0aW9uLg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206IElkciA8aWRyLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9m IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+DQpE YXRlOiBGcmlkYXksIERlY2VtYmVyIDgsIDIwMTcgYXQgMTI6MTAgUE0NClRvOiBJRFIgTGlzdCA8 aWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0lkcl0gRWFybHkg Q29kZSBQb2ludCBhbGxvY2F0aW9uIGZvciBkcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9u LTA1ICgxMi84IHRvIDEyLzIyKQ0KDQpUaGlzIGJlZ2lucyBhICB3ZWVrIFdHIGNhbGwgZm9yIGFw cHJvdmFsIG9mIGVhcmx5IGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1lYWct ZGlzdHJpYnV0aW9uLTA1LnR4dC4NCllvdSBjYW4gdmlldyB0aGUgc3BlY2lmaWNhdGlvbiBhdDoN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaWRyLWVhZy1kaXN0 cmlidXRpb24vDQoNClRoZSBzcGVjaWZpY2F0aW9uIGhhcyBnb25lIHRocm91Z2ggNSByZXZpc2lv bnMuICBUaGVyZSBhcmUgdHdvIG9yZ2FuaXphdGlvbnMgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRp bmcgdGhpcyBzcGVjaWZpY2F0aW9uLiAgIFBsZWFzZSBzZW5kIGluIHlvdXIgY29tbWVudHMgYnkg MTIvMjIuDQoNClN1c2FuIEhhcmVzDQo= --_000_a6469f0d367c48e2a062276f6ca9a785XCHALN014ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciLHNlcmlmOw0KCWNvbG9yOiM3MDMwQTA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2Nv bG9yOiM3MDMwQTAiPkkgc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtjb2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWY7 Y29sb3I6IzcwMzBBMCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmO2NvbG9yOiM3MDMwQTAiPkpha29iPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZjtj b2xvcjojNzAzMEEwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElk ciBbbWFpbHRvOmlkci1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5TdXNh biBIYXJlczxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDgsIDIwMTcgMTA6NTIg QU08YnI+DQo8Yj5Ubzo8L2I+IEFjZWUgTGluZGVtIChhY2VlKSAmbHQ7YWNlZUBjaXNjby5jb20m Z3Q7OyBpZHJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIEVhcmx5IENv ZGUgUG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3RyaWJ1dGlvbi0w NSAoMTIvOCB0byAxMi8yMik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BY2VlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB3aXRoIHlvdXIgdmlld3BvaW50LiAmbmJzcDsmbmJzcDtJ RFIgYW5kIElTSVMvT1NQRiBhcmUgdmVyeSB0aG91Z2h0ZnVsIGFib3V0IHRoZSBkcmFmdHMgdGhl eSBhZG9wdC4gJm5ic3A7VGhlIElEUiBXRyBoYXMgY2xlYXJseSBzdGF0ZWQgdGhleSB3YW50IGFs bG9jYXRpb25zIGRvbmUgd2hlbmV2ZXIgcG9zc2libGUuIEhvd2V2ZXIsIEkgaGF2ZSBnb3R0ZW4g cHVzaC1iYWNrDQogZnJvbSB0aGlzIElFU0cuICZuYnNwOyZuYnNwO1NvLCBJ4oCZdmUgbWFkZSB0 aGlzIGNhbGwgdG8gdGhlIFdHLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlN1ZSBIYXJlcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBJZHIgWzxh IGhyZWY9Im1haWx0bzppZHItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmlkci1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgOCwgMjAxNyAxMjozNSBQTTxicj4NCjxiPlRv OjwvYj4gU3VzYW4gSGFyZXM7IDxhIGhyZWY9Im1haWx0bzppZHJAaWV0Zi5vcmciPmlkckBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJZHJdIEVhcmx5IENvZGUgUG9pbnQg YWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3RyaWJ1dGlvbi0wNSAoMTIvOCB0 byAxMi8yMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkhpIFN1ZSwm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkkgc3VwcG9ydCBl YXJseSBhbGxvY2F0aW9uLiBJbiBmYWN0LCBmb3IgV0cgZG9jdW1lbnRzIEkgdGhpbmsgd2Ugc2hv dWxkbuKAmXQgcGxhY2Ugc3VjaCBhIGhpZ2ggYmFyIG9uIGVhcmx5IGFsbG9jYXRpb24uJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkFjZWUmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZHIgJmx0OzxhIGhyZWY9Im1haWx0bzppZHItYm91bmNl c0BpZXRmLm9yZyI+aWRyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3Vz YW4gSGFyZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iPnNoYXJlc0BuZHpo LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgRGVjZW1iZXIgOCwgMjAxNyBh dCAxMjoxMCBQTTxicj4NCjxiPlRvOiA8L2I+SURSIExpc3QgJmx0OzxhIGhyZWY9Im1haWx0bzpp ZHJAaWV0Zi5vcmciPmlkckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJ ZHJdIEVhcmx5IENvZGUgUG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRp c3RyaWJ1dGlvbi0wNSAoMTIvOCB0byAxMi8yMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0 LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCIgaWQ9Ik1BQ19P VVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoaXMgYmVnaW5zIGEmbmJzcDsg d2VlayBXRyBjYWxsIGZvciBhcHByb3ZhbCBvZiBlYXJseSBjb2RlIHBvaW50IGFsbG9jYXRpb24g Zm9yIGRyYWZ0LWlldGYtZWFnLWRpc3RyaWJ1dGlvbi0wNS50eHQuJm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPllvdSBjYW4gdmlldyB0aGUgc3BlY2lmaWNhdGlvbiBhdDoNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItZWFn LWRpc3RyaWJ1dGlvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaWRyLWVhZy1kaXN0cmlidXRpb24vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5UaGUgc3BlY2lmaWNhdGlvbiBoYXMgZ29uZSB0aHJvdWdoIDUgcmV2aXNpb25zLiZuYnNw OyBUaGVyZSBhcmUgdHdvIG9yZ2FuaXphdGlvbnMgaW50ZXJlc3RlZCBpbiBpbXBsZW1lbnRpbmcg dGhpcyBzcGVjaWZpY2F0aW9uLiZuYnNwOyZuYnNwOyBQbGVhc2Ugc2VuZCBpbiB5b3VyIGNvbW1l bnRzIGJ5IDEyLzIyLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlN1 c2FuIEhhcmVzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_a6469f0d367c48e2a062276f6ca9a785XCHALN014ciscocom_-- From nobody Sat Dec 9 22:27:30 2017 Return-Path: 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 8B2C7126CB6 for ; Sat, 9 Dec 2017 22:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 w1o9Bwkxe81d for ; Sat, 9 Dec 2017 22:27:27 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 002FF126BF0 for ; Sat, 9 Dec 2017 22:27:26 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id i11so8897873wmf.4 for ; Sat, 09 Dec 2017 22:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NTXWTOW8ADHuTtGOUsfDSu+u5YuouOnurRELD8eHz0M=; b=Mgt9IvTT/miw0EoRH4PIRPogzy2aQbNK+7okMI6HQjTSv3S3Vp/YuPy8wn+FwD5v0T FFqcI5nkCQSMdCFWLhycRHmOUBACWw4EMq5Ci05kJdbor69K/o8Lq2OeUfq6J6NCkoiu 7uwVBr7gzAbbBtNQzXwwDUYFbHV1M1P+lwtfXLyOHYizE5x9P/Rz8JHTxLAlppNvAlVr nXB+PQ+Hzu7fgjbJlkZvIiQ2G2h4cywjwolOkyqULJuCW2oeg2Jy7+leGa5taed6ZTbI tjuWG5j3bdzgBdXJn9oI0lbm1ksz03qcS3DBz+dc6yKwjQoWUuwIZ03Vu0rNlR8XMPsr gkmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NTXWTOW8ADHuTtGOUsfDSu+u5YuouOnurRELD8eHz0M=; b=Mn8zOGesZ1bVHBal8eKm2YxkLmmLrh2zC49QmXMAM9SptnduvBklR7+meK5LlQEpaB R+8YBYxlUpfqTOC48WPQiRvXl6OXeMcIzge39UxJ/LrRzkJH9lzBjdxIEp4+DX5RS2Ez S+uWVM8VP8jYRMYBP4NgbdkuQ0RDHFs+dAbAR98r8M7oTQFUX3KDw4XLSFMUWAQDQAKq svTaTx0ro/dKirN9kAQpHZpl4h1ZdlhEZea18kakPgkxmB/oMajmyDS3j0ptWSCJoeRC nbPBlV1yRuk/1/9ru4RB/2HAzzyRUxLC2HV/YJx2TPJ0Bn56vuuLe02etpoLosobzTKc MuTw== X-Gm-Message-State: AKGB3mK7PxcpNnsHFi+6EgRhGvVMo07mcnECAPBIfraEXlCplwu2xmOb ge9iIv8FkwLeL6c+6I6Vg0U= X-Google-Smtp-Source: AGs4zMYw0/3ITF2eRrI2Ddgqn63KRlfAK9OeDZeRFS3pNG3u0uHRBVc1RkiTtnc34SFW1upp1EiqhA== X-Received: by 10.28.16.144 with SMTP id 138mr7198705wmq.155.1512887245440; Sat, 09 Dec 2017 22:27:25 -0800 (PST) Received: from [10.76.156.99] ([217.145.241.210]) by smtp.gmail.com with ESMTPSA id a74sm16870987wrc.7.2017.12.09.22.27.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Dec 2017 22:27:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kireeti Kompella X-Mailer: iPhone Mail (15A421) In-Reply-To: Date: Sun, 10 Dec 2017 09:27:22 +0300 Cc: Thomas Mangin , idr@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> To: Randy Bush Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 06:27:29 -0000 On Dec 9, 2017, at 23:26, Randy Bush wrote: >> I would support a reasonable increase 255 or more. > > 640 is a tempting classic choice 640K is what you meant, right? Kireeti > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Sat Dec 9 23:35:02 2017 Return-Path: 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 798E91200F3; Sat, 9 Dec 2017 23:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PZGbxsPeOZn; Sat, 9 Dec 2017 23:34:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 5CBED1200C5; Sat, 9 Dec 2017 23:34:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eNw8T-0000pa-LC; Sun, 10 Dec 2017 07:34:53 +0000 Date: Sat, 09 Dec 2017 23:34:52 -0800 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi (Fed)" Cc: "jhaas@pfrc.org" , Robert Raszuk , Jakob Heitz , IDR , "idr-ads@ietf.org" , "draft-ietf-idr-bgp-extended-messages@ietf.org" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] WG Last Call foir draft-ietf-idr-bgp-extended-messages (11/12 to 11/26) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 07:35:00 -0000 > It was estimated that the maximum BGPsec_PATH attribute size > is not expected to exceed 4KB in the foreseeable future. perhaps the use of passive voice is not appropriate? From nobody Mon Dec 11 11:44:22 2017 Return-Path: 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 5F2AC126DD9 for ; Mon, 11 Dec 2017 11:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 6LaDY4l93Umb for ; Mon, 11 Dec 2017 11:44:19 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BA4124D68 for ; Mon, 11 Dec 2017 11:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3586; q=dns/txt; s=iport; t=1513021459; x=1514231059; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fw/99IX+JKa9/5y3G8rOBNlE8fCE8B2NJAkFn/sgWBk=; b=FV9bqx8/ruDT9obb/NojZTFSP6NDjku74jrMpjVm4+pAcaTDqmIse9Z/ V4TjGZ+nFoDv/+wt/hD2VMtzLwqiF+QYNUuVDVrTWmgmMkNOq2yzYStSo xEYhJ4/ndY3Sdv4MXbPJr7aaHC8Pj3S2c+m6JLLb69ESaa5XVfMyJ3zFh s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7CgD93i5a/40NJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0JwecfAEdgX2BWpVGggEKGA2FFgKEckMUAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQEDAQE4NBcEAgEIEQMBAQEfCQcnCxQJCAIEARIIiiAQqlOKZAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DaIFhASmBVoUUgzKBMQQShh4Fkg+RAgKHd40?= =?us-ascii?q?fgh9jhS+LO4pBgkmJJwIRGQGBOgE2IoFPbxUWJIIpCYJGH4FneAGHF4EygRUBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.45,392,1508803200"; d="scan'208";a="324922559" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2017 19:44:18 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vBBJiIJs019193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Dec 2017 19:44:18 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 13:44:17 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Mon, 11 Dec 2017 13:44:17 -0600 From: "Jakob Heitz (jheitz)" To: Job Snijders , "idr@ietf.org" Thread-Topic: [Idr] draft-snijders-idr-rfc8203bis Thread-Index: AQHTcDvoN5NHVY0xNUqvjmXbgd8Js6M+i0Cw Date: Mon, 11 Dec 2017 19:44:17 +0000 Message-ID: References: <20171208154735.GH61799@vurt.meerval.net> In-Reply-To: <20171208154735.GH61799@vurt.meerval.net> 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.154.131.22] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 19:44:21 -0000 Cyrillic characters are 2 bytes each and they use about the same number of characters per word as english. Chinese characters are 3 bytes, but most Chinese words are only 1 or 2 characters and they don't use a space character. Hiragana, Katakana and Hangul are 3 bytes per character and each character encodes a syllable. My knowledge about this is sketchy, so I might be missing something. Can we have some perspective from other people using other languages please= . Thanks, Jakob -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders Sent: Friday, December 8, 2017 7:48 AM To: idr@ietf.org Subject: [Idr] draft-snijders-idr-rfc8203bis Dear IDR, So, it appears I was wrong to push for the arbitrary maximum length of 128 octets when we worked on the BGP Administrative Shutdown Communication (RFC 8203). At the time, multiple people pointed out that it might be better to let the the thing be a little bit longer (255), and in retrospect that indeed would've been better. I'm sorry :( At this month's peering forum meeting of the Moscow Internet Exchange, Misha Grishin (MSK-IX) reported on experiences with the shutdown communication, and indicated that the concept was considered useful, but that 128 octets is too small in context of multibyte character sets such as Cyrillic script and they couldn't easily fit the short messages they wanted to send in the communication. The GoBGP authors also questioned the 128 limit during the implementation phase, I now see why. Operational feedback like this is invaluable and worth our consideration. I think that allowing all possible values in the shutdown communication length field will allow more societies to use the shutdown communication feature in their native script, and this outweights the additional risk of visual spoofing that an additional 127 octets could bring. I think it won't be too hard to update the existing implementations. We've posted a short draft to update use of the length field in rfc8203. Thoughts? Kind regards, Job ----- Forwarded message from internet-drafts@ietf.org ----- Date: Fri, 08 Dec 2017 07:22:57 -0800 From: internet-drafts@ietf.org To: Job Snijders , Alexander Azimov Subject: New Version Notification for draft-snijders-idr-rfc8203bis-00.txt A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt has been successfully submitted by Job Snijders and posted to the IETF repository. Name: draft-snijders-idr-rfc8203bis Revision: 00 Title: Extended BGP Administrative Shutdown Communication Document date: 2017-12-07 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-snijders-idr-rfc= 8203bis-00.txt Status: https://datatracker.ietf.org/doc/draft-snijders-idr-rfc8203= bis/ Htmlized: https://tools.ietf.org/html/draft-snijders-idr-rfc8203bis-0= 0 Htmlized: https://datatracker.ietf.org/doc/html/draft-snijders-idr-rf= c8203bis-00 Abstract: This document updates RFC8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----- End forwarded message ----- _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Dec 11 13:01:03 2017 Return-Path: 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 182CD128961 for ; Mon, 11 Dec 2017 13:01:03 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=highloadlab-com.20150623.gappssmtp.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 q05cNMPbvFb1 for ; Mon, 11 Dec 2017 13:00:59 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 192E31273B1 for ; Mon, 11 Dec 2017 13:00:59 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id j124so12475997pfc.2 for ; Mon, 11 Dec 2017 13:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=highloadlab-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N798TYtwabt3uuWbTylMp8Gg7nARxWF6m/EMjKFnMZg=; b=qych6wVAWRfwrVM2+yP/b+6tdAFOuB/DfD7jIeL7PajJUK/ewMTr4KxrsK/sgPdPRd IoShpMm084MpFhlQsbX01TXeLiDMtT9yntqHZ+AnFZWHUi8bEg2rGo0KQkk8uYRQCwM4 sefWfxkj11+fSAVjKhs6NiGRvrK2dzcpUqq+oZU/XRf20RcmcvQltHEHwOJMBAxq+1Y0 X30LnVinGBx3ET3IPd1cTVZJNmz3385p0BH9bWvGma+GnjUAkwq49TQsy+uzjMr6Etu1 wJjdCCWTdEdhJUzR6lbNy2+sdgCSMMQpzmIRf+u3Qg5IrfnPGsCLbt1mmyaXr4tkx+3p odLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N798TYtwabt3uuWbTylMp8Gg7nARxWF6m/EMjKFnMZg=; b=YuQYjGBrerPeKoqABatkDY1FMO5CkwqkZEmrZgFD4egM1zAbTgalUk8geri0ycKHys JVjgNWxf6NQ8x9Bw7SajmLL2HCYYw0Mdk/+YAqx4c285UEyVIZ1jv/3BnvTV1SBtEcAR KpUgStT7W09d70e/i8LslZYOJu6HZ0HkTJkkjyzdsKRso4aGDay9euD/4mu0f2cbUayF Zrq1hPXWTGl0VhZDcrlLB56UKJMH7zhF188v1D+yiAFQGoHIePJvsB15VIfQ6GkDmsEE x3C6CI4Y4xtY67S/0tUV/k3oRfRN7Er02UgEpEFAzXOxhqxuOxVbamLlLcNweHOc8RXe fApw== X-Gm-Message-State: AKGB3mL8MRivtmTYoVuzdBJZts1gBBNkwfbfYOXs0wa+JHoSsd/u2HdK jp95GxzN1VoCZ0Mh8weO4h1Id5CWKhnPxkjWInWj1Q== X-Google-Smtp-Source: ACJfBovxKWeKLQaLMDEGOnzHUmNMu3UOnQ3jB61fsB7HI9UKYpBwjsyJdS/DyC5HulSItbIE0vDgE0yY7KxlFIcjtB4= X-Received: by 10.84.167.2 with SMTP id c2mr1541853plb.25.1513026058330; Mon, 11 Dec 2017 13:00:58 -0800 (PST) MIME-Version: 1.0 Sender: aa@highloadlab.com Received: by 10.100.128.81 with HTTP; Mon, 11 Dec 2017 13:00:57 -0800 (PST) X-Originating-IP: [46.188.121.185] In-Reply-To: References: <20171208154735.GH61799@vurt.meerval.net> From: Alexander Azimov Date: Tue, 12 Dec 2017 00:00:57 +0300 X-Google-Sender-Auth: 5q9igeLwuRVJicnPvYRUKPS1JwU Message-ID: To: "Jakob Heitz (jheitz)" Cc: Job Snijders , "idr@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c145baebe38a1056016d4d4" Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:01:03 -0000 --94eb2c145baebe38a1056016d4d4 Content-Type: text/plain; charset="UTF-8" I can only confirm that for common notifications in Russian 255 should be enough. 2017-12-11 22:44 GMT+03:00 Jakob Heitz (jheitz) : > Cyrillic characters are 2 bytes each and they use about the same number > of characters per word as english. Chinese characters are 3 bytes, but most > Chinese words are only 1 or 2 characters and they don't use a space > character. Hiragana, Katakana and Hangul are 3 bytes per character > and each character encodes a syllable. > > My knowledge about this is sketchy, so I might be missing something. > > Can we have some perspective from other people using other languages > please. > > Thanks, > Jakob > > > -----Original Message----- > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders > Sent: Friday, December 8, 2017 7:48 AM > To: idr@ietf.org > Subject: [Idr] draft-snijders-idr-rfc8203bis > > Dear IDR, > > So, it appears I was wrong to push for the arbitrary maximum length of > 128 octets when we worked on the BGP Administrative Shutdown > Communication (RFC 8203). At the time, multiple people pointed out that > it might be better to let the the thing be a little bit longer (255), > and in retrospect that indeed would've been better. I'm sorry :( > > At this month's peering forum meeting of the Moscow Internet Exchange, > Misha Grishin (MSK-IX) reported on experiences with the shutdown > communication, and indicated that the concept was considered useful, but > that 128 octets is too small in context of multibyte character sets such > as Cyrillic script and they couldn't easily fit the short messages they > wanted to send in the communication. The GoBGP authors also questioned > the 128 limit during the implementation phase, I now see why. > Operational feedback like this is invaluable and worth our > consideration. > > I think that allowing all possible values in the shutdown communication > length field will allow more societies to use the shutdown communication > feature in their native script, and this outweights the additional risk > of visual spoofing that an additional 127 octets could bring. I think > it won't be too hard to update the existing implementations. > > We've posted a short draft to update use of the length field in rfc8203. > > Thoughts? > > Kind regards, > > Job > > ----- Forwarded message from internet-drafts@ietf.org ----- > > Date: Fri, 08 Dec 2017 07:22:57 -0800 > From: internet-drafts@ietf.org > To: Job Snijders , Alexander Azimov > Subject: New Version Notification for draft-snijders-idr-rfc8203bis-00.txt > > > A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt > has been successfully submitted by Job Snijders and posted to the > IETF repository. > > Name: draft-snijders-idr-rfc8203bis > Revision: 00 > Title: Extended BGP Administrative Shutdown Communication > Document date: 2017-12-07 > Group: Individual Submission > Pages: 4 > URL: https://www.ietf.org/internet-drafts/draft-snijders-idr- > rfc8203bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-snijders-idr- > rfc8203bis/ > Htmlized: https://tools.ietf.org/html/draft-snijders-idr-rfc8203bis- > 00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-snijders-idr- > rfc8203bis-00 > > > Abstract: > This document updates RFC8203 by defining an Extended BGP > Administrative Shutdown Communication to improve communication using > multibyte character sets. > > > 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. > > The IETF Secretariat > > > ----- End forwarded message ----- > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- | Alexander Azimov | HLL l QRATOR | tel.: +7 499 241 81 92 | mob.: +7 915 360 08 86 | skype: mitradir | mailto: aa@qrator.net | visit: www.qrator.net --94eb2c145baebe38a1056016d4d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can only confirm that for common notifications in Russia= n 255 should be enough.

2017-12-11 22:44 GMT+03:00 Jakob Heitz (jheitz) <jheitz@cisco.c= om>:
Cyrillic characters ar= e 2 bytes each and they use about the same number
of characters per word as english. Chinese characters are 3 bytes, but most=
Chinese words are only 1 or 2 characters and they don't use a space
character. Hiragana, Katakana and Hangul are 3 bytes per character
and each character encodes a syllable.

My knowledge about this is sketchy, so I might be missing something.

Can we have some perspective from other people using other languages please= .

Thanks,
Jakob


-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.= org] On Behalf Of Job Snijders
Sent: Friday, December 8, 2017 7:48 AM
To: idr@ietf.org
Subject: [Idr] draft-snijders-idr-rfc8203bis

Dear IDR,

So, it appears I was wrong to push for the arbitrary maximum length of
128 octets when we worked on the BGP Administrative Shutdown
Communication (RFC 8203). At the time, multiple people pointed out that
it might be better to let the the thing be a little bit longer (255),
and in retrospect that indeed would've been better. I'm sorry :(
At this month's peering forum meeting of the Moscow Internet Exchange,<= br> Misha Grishin (MSK-IX) reported on experiences with the shutdown
communication, and indicated that the concept was considered useful, but that 128 octets is too small in context of multibyte character sets such as Cyrillic script and they couldn't easily fit the short messages they=
wanted to send in the communication. The GoBGP authors also questioned
the 128 limit during the implementation phase, I now see why.
Operational feedback like this is invaluable and worth our
consideration.

I think that allowing all possible values in the shutdown communication
length field will allow more societies to use the shutdown communication feature in their native script, and this outweights the additional risk
of visual spoofing that an additional 127 octets could bring. I think
it won't be too hard to update the existing implementations.

We've posted a short draft to update use of the length field in rfc8203= .

Thoughts?

Kind regards,

Job

----- Forwarded message from in= ternet-drafts@ietf.org -----

Date: Fri, 08 Dec 2017 07:22:57 -0800
From: internet-drafts@ietf.org<= /a>
To: Job Snijders <job@ntt.net>, Al= exander Azimov <aa@qrator.net> Subject: New Version Notification for draft-snijders-idr-rfc8203bis-00= .txt


A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt
has been successfully submitted by Job Snijders and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-snijders-idr-rfc8203bis=
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extended BGP Administrative Shutdo= wn Communication
Document date:=C2=A0 2017-12-07
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-snijders= -idr-rfc8203bis-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-snijders-idr-rfc8203bi= s/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://tools.ietf.org/html/draft-snijders-idr-rfc8203bis-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-snijders-idr-rf= c8203bis-00


Abstract:
=C2=A0 =C2=A0This document updates RFC8203 by defining an Extended BGP
=C2=A0 =C2=A0Administrative Shutdown Communication to improve communication= using
=C2=A0 =C2=A0multibyte character sets.


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

The IETF Secretariat


----- End forwarded message -----

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

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



--
=
| Alexander Azimov =C2=A0| HLL l QRATOR<= /font>
| tel.: +7 499 241 81 92
=
| mob.: +7 915 360 08 86
| skype: mitradir
| m= ailto:=C2=A0aa@qrator.ne= t
| visit:=C2=A0www.qrator.net
--94eb2c145baebe38a1056016d4d4-- From nobody Mon Dec 11 13:04:03 2017 Return-Path: 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 015261289B5 for ; Mon, 11 Dec 2017 13:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 06Qk5FfAQW_S for ; Mon, 11 Dec 2017 13:03:59 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD194128954 for ; Mon, 11 Dec 2017 13:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6808; q=dns/txt; s=iport; t=1513026238; x=1514235838; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kLq1k2A9m9TpZbVeIIGstQEOePQBiS7Z335lfsSIQGw=; b=GUsPjhlvjERrDoIiUHHIM4Dv3rg55hrblBY/r0nh52FJsP+YwJd4K2nR FWNMFDV3isDZ58tyCKuAqJ75Yf7lpfyWTzlA36Df9PzeEn+T/lJ3g0LLL wlwDHCvfO3tXc/2AdDx5v0FVAFmzFdUhcPjTW4tGyqEiRthJlIMIehjkc o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C5EQBQ8i5a/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKdGZ0JweDe5kCAR2BVyaBWo9nh2AKI4UYAhqEWEIVAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQEDHQZmAgEIDgMDAQIrAgICMB0IAgQBEolEZBCoMoInJoo9A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDaIFhASmBVoISC4JBNoMygg2CdTGCMgW?= =?us-ascii?q?ZS4lGAod3jSiCFoYSizuNCoknAhEZAYE6ATUjgU9vFWQBgX6DB4FOeIhKgRUBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos; i="5.45,392,1508803200"; d="scan'208,217"; a="42716134" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 21:03:57 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBBL3vi7010961 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Dec 2017 21:03:57 GMT Received: from xch-rtp-012.cisco.com (64.101.220.152) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Dec 2017 16:03:56 -0500 Received: from xch-rtp-012.cisco.com ([64.101.220.152]) by XCH-RTP-012.cisco.com ([64.101.220.152]) with mapi id 15.00.1320.000; Mon, 11 Dec 2017 16:03:56 -0500 From: "Gaurav Dawra (gdawra)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) Thread-Index: AQHTcsOOYoKvSDJK906dOzat1OL9Dw== Date: Mon, 11 Dec 2017 21:03:56 +0000 Message-ID: <04CCB138-526F-4914-BBAD-9067E31784D3@cisco.com> References: <014101d37047$63eef530$2bccdf90$@ndzh.com> In-Reply-To: <014101d37047$63eef530$2bccdf90$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.32.198.232] Content-Type: multipart/alternative; boundary="_000_04CCB138526F4914BBAD9067E31784D3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:04:01 -0000 --_000_04CCB138526F4914BBAD9067E31784D3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGVhcmx5IGFsbG9jYXRpb24uDQoNClJlZ2FyZHMsDQoNCkdhdXJhdg0KDQpGcm9t OiBJZHIgPGlkci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgU3VzYW4gSGFyZXMgPHNo YXJlc0BuZHpoLmNvbT4NCkRhdGU6IEZyaWRheSwgRGVjZW1iZXIgOCwgMjAxNyBhdCA5OjEwIEFN DQpUbzogImlkckBpZXRmLm9yZyIgPGlkckBpZXRmLm9yZz4NClN1YmplY3Q6IFtJZHJdIEVhcmx5 IENvZGUgUG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3RyaWJ1dGlv bi0wNSAoMTIvOCB0byAxMi8yMikNCg0KVGhpcyBiZWdpbnMgYSAgd2VlayBXRyBjYWxsIGZvciBh cHByb3ZhbCBvZiBlYXJseSBjb2RlIHBvaW50IGFsbG9jYXRpb24gZm9yIGRyYWZ0LWlldGYtZWFn LWRpc3RyaWJ1dGlvbi0wNS50eHQuDQpZb3UgY2FuIHZpZXcgdGhlIHNwZWNpZmljYXRpb24gYXQ6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1lYWctZGlz dHJpYnV0aW9uLw0KDQpUaGUgc3BlY2lmaWNhdGlvbiBoYXMgZ29uZSB0aHJvdWdoIDUgcmV2aXNp b25zLiAgVGhlcmUgYXJlIHR3byBvcmdhbml6YXRpb25zIGludGVyZXN0ZWQgaW4gaW1wbGVtZW50 aW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4gICBQbGVhc2Ugc2VuZCBpbiB5b3VyIGNvbW1lbnRzIGJ5 IDEyLzIyLg0KDQpTdXNhbiBIYXJlcw0K --_000_04CCB138526F4914BBAD9067E31784D3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJHZW9yZ2lhIixzZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+SSBzdXBwb3J0IGVhcmx5IGFsbG9jYXRpb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsYWNrIj5HYXVyYXY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPklkciAmbHQ7 aWRyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAmbHQ7c2hh cmVzQG5kemguY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIERlY2VtYmVyIDgsIDIw MTcgYXQgOToxMCBBTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7aWRyQGlldGYub3JnJnF1b3Q7ICZs dDtpZHJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJZHJdIEVhcmx5IENvZGUg UG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1pZHItZWFnLWRpc3RyaWJ1dGlvbi0wNSAo MTIvOCB0byAxMi8yMik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBiZWdpbnMgYSZuYnNwOyB3ZWVrIFdHIGNhbGwgZm9yIGFwcHJvdmFs IG9mIGVhcmx5IGNvZGUgcG9pbnQgYWxsb2NhdGlvbiBmb3IgZHJhZnQtaWV0Zi1lYWctZGlzdHJp YnV0aW9uLTA1LnR4dC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WW91IGNhbiB2aWV3IHRoZSBzcGVjaWZpY2F0aW9uIGF0OiA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtaWRyLWVhZy1kaXN0cmlidXRpb24vIj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlkci1lYWctZGlzdHJpYnV0aW9uLzwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNwZWNpZmljYXRpb24gaGFzIGdvbmUgdGhyb3VnaCA1IHJl dmlzaW9ucy4mbmJzcDsgVGhlcmUgYXJlIHR3byBvcmdhbml6YXRpb25zIGludGVyZXN0ZWQgaW4g aW1wbGVtZW50aW5nIHRoaXMgc3BlY2lmaWNhdGlvbi4mbmJzcDsmbmJzcDsgUGxlYXNlIHNlbmQg aW4geW91ciBjb21tZW50cyBieSAxMi8yMi4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TdXNhbiBIYXJlcyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_04CCB138526F4914BBAD9067E31784D3ciscocom_-- From nobody Mon Dec 11 13:18:04 2017 Return-Path: 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 3EF96128B27 for ; Mon, 11 Dec 2017 13:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 s3Qyqo0DXhgO for ; Mon, 11 Dec 2017 13:17:59 -0800 (PST) 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 8E2761288B8 for ; Mon, 11 Dec 2017 13:17:59 -0800 (PST) Received: from 80-110-97-151.cgn.dynamic.surfer.at ([80.110.97.151] helo=[192.168.66.220]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1eOVBM-0006KH-TX; Mon, 11 Dec 2017 22:00:14 +0100 From: Christoph Loibl Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_CF7ABC7A-A68F-43A7-864F-CE127778A03F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 11 Dec 2017 22:17:54 +0100 In-Reply-To: <20171208154735.GH61799@vurt.meerval.net> Cc: idr wg To: Job Snijders References: <20171208154735.GH61799@vurt.meerval.net> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:18:02 -0000 --Apple-Mail=_CF7ABC7A-A68F-43A7-864F-CE127778A03F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Job, and many others, First of all: I did not read up the discussion that may have led to the = 128 byte limit specified in RFC 8203 but I can see that the message = limit was there right from the beginning as some sort of security = measure. I also see that the explicit length field has been introduced = very soon after/during WG adoption, even though we usually rely on the = BGP-message header length-field when it comes to the length of the data = field in notification messages. Sorry if I revive a discussion that was = there Does this imposed limit really improve security in any way or save us = from UTF-8 based hacks? BGP constantly receives all sorts of messages = (usually more complex messages than this particular notification) from = unknown neighbours and usually unknown BGP-implementations. Screening = received messages is crucial anyway. When changing the limit, why bother = with another length (and how do we decide for the right length - is it = because of russian? chinese?, ...)? Only to find it inconvenient in = another unforeseen situation/message/language soon? I am tempted to say, = that from design, it is a 4k-message size (minus some 20++ bytes). Cheers Christoph -- Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 08.12.2017, at 16:47, Job Snijders wrote: >=20 > Dear IDR, >=20 > So, it appears I was wrong to push for the arbitrary maximum length of > 128 octets when we worked on the BGP Administrative Shutdown > Communication (RFC 8203). At the time, multiple people pointed out = that > it might be better to let the the thing be a little bit longer (255), > and in retrospect that indeed would've been better. I'm sorry :( >=20 > At this month's peering forum meeting of the Moscow Internet Exchange, > Misha Grishin (MSK-IX) reported on experiences with the shutdown > communication, and indicated that the concept was considered useful, = but > that 128 octets is too small in context of multibyte character sets = such > as Cyrillic script and they couldn't easily fit the short messages = they > wanted to send in the communication. The GoBGP authors also questioned > the 128 limit during the implementation phase, I now see why. > Operational feedback like this is invaluable and worth our > consideration. >=20 > I think that allowing all possible values in the shutdown = communication > length field will allow more societies to use the shutdown = communication > feature in their native script, and this outweights the additional = risk > of visual spoofing that an additional 127 octets could bring. I think > it won't be too hard to update the existing implementations. >=20 > We've posted a short draft to update use of the length field in = rfc8203. >=20 > Thoughts? >=20 > Kind regards, >=20 > Job >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Fri, 08 Dec 2017 07:22:57 -0800 > From: internet-drafts@ietf.org > To: Job Snijders , Alexander Azimov > Subject: New Version Notification for = draft-snijders-idr-rfc8203bis-00.txt >=20 >=20 > A new version of I-D, draft-snijders-idr-rfc8203bis-00.txt > has been successfully submitted by Job Snijders and posted to the > IETF repository. >=20 > Name: draft-snijders-idr-rfc8203bis > Revision: 00 > Title: Extended BGP Administrative Shutdown = Communication > Document date: 2017-12-07 > Group: Individual Submission > Pages: 4 > URL: = https://www.ietf.org/internet-drafts/draft-snijders-idr-rfc8203bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-snijders-idr-rfc8203bis/ > Htmlized: = https://tools.ietf.org/html/draft-snijders-idr-rfc8203bis-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-snijders-idr-rfc8203bis-00 >=20 >=20 > Abstract: > This document updates RFC8203 by defining an Extended BGP > Administrative Shutdown Communication to improve communication using > multibyte character sets. >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 > ----- End forwarded message ----- >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_CF7ABC7A-A68F-43A7-864F-CE127778A03F 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 iF0EARECAB0WIQQ49wVNibKs7fQYJYbSbYynSywAVQUCWi72AgAKCRDSbYynSywA VSKnAKD3FUfVOfLxh1aF5Cye1q4XBVOQ3gCcCsafmIBsN8RUOFDP0X1EuFnj4v8= =rCq7 -----END PGP SIGNATURE----- --Apple-Mail=_CF7ABC7A-A68F-43A7-864F-CE127778A03F-- From nobody Mon Dec 11 13:36:29 2017 Return-Path: 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 0545A1289C3 for ; Mon, 11 Dec 2017 13:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzlGGtVG2RGa for ; Mon, 11 Dec 2017 13:36:26 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E3C42124217 for ; Mon, 11 Dec 2017 13:36:25 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 7272C1E336; Mon, 11 Dec 2017 16:40:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: Date: Mon, 11 Dec 2017 16:36:23 -0500 Cc: Job Snijders , idr wg Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171208154735.GH61799@vurt.meerval.net> To: Christoph Loibl X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 21:36:28 -0000 > On Dec 11, 2017, at 4:17 PM, Christoph Loibl wrote: >=20 > Hi Job, and many others, >=20 > First of all: I did not read up the discussion that may have led to = the 128 byte limit specified in RFC 8203 but I can see that the message = limit was there right from the beginning as some sort of security = measure. I also see that the explicit length field has been introduced = very soon after/during WG adoption, even though we usually rely on the = BGP-message header length-field when it comes to the length of the data = field in notification messages. Sorry if I revive a discussion that was = there >=20 > Does this imposed limit really improve security in any way or save us = from UTF-8 based hacks? BGP constantly receives all sorts of messages = (usually more complex messages than this particular notification) from = unknown neighbours and usually unknown BGP-implementations. Screening = received messages is crucial anyway. When changing the limit, why bother = with another length (and how do we decide for the right length - is it = because of russian? chinese?, ...)? Only to find it inconvenient in = another unforeseen situation/message/language soon? I am tempted to say, = that from design, it is a 4k-message size (minus some 20++ bytes). In my opinion: To loosely quote someone else on this list, "constants are almost always = wrong". (In the mis-sized sense.) As you note, the BGP protocol already bounds the size of the message, = although NOTIFICATION is one of the few places where you could send = almost complete nonsense and have zero recourse. But if you presume a = 4k max size, sending implementations may choose to send a max-length = message. Receiving implementations are perfectly free to truncate the = received message if they find it appropriate. This is an important distinction. For example, it might be reasonable = to receive a 4k human-readable message, print it, but not store it = indefinitely in your BGP data structures. =20 A general issue with trying to right-size a human-readable buffer is = simply language information density. Some languages are lower-density = than others with regards to character encoding. Just because you can = encode full words in many asian languages in 4-octets of UTF-8, should = you penalize languages that require 20+ for the same word? Similarly, nouns contribute to the overhead. Even if the language is = dense, you may still need to fallback to other character sets to = represent common things such as human-readable IP addresses, phone = numbers, place names, etc. While I don't intend to try to turn this into twitter-over-BGP and = whether 140 vs. 280 characters is the right thing, I will suggest that = attempts to try to constrain things too much cause more problems than = they're worth. Instead, I'd suggest: 1. The limit of the message should be on the order of what's available = in the PDU. 2. Users should be cautioned that receiving implementations are = permitted to truncate (using UTF-8 rules) incoming messages. 3. Given 2, use good "answering machine" discipline and make sure the = important data is toward the start of the message. E.g. ticket #, phone = #, etc. -- Jeff From nobody Tue Dec 12 04:17:20 2017 Return-Path: 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 81260129438 for ; Tue, 12 Dec 2017 04:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0f0LXP6XlucY for ; Tue, 12 Dec 2017 04:17:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 D59B3126CD8 for ; Tue, 12 Dec 2017 04:17:16 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A9A58E2F54739 for ; Tue, 12 Dec 2017 12:17:13 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 12 Dec 2017 12:17:14 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0361.001; Tue, 12 Dec 2017 20:17:07 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) Thread-Index: AdNwR0Ep3YRSQoYwSe+55gJblUBfMAC+5MXQ Date: Tue, 12 Dec 2017 12:17:06 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927981D55E3@NKGEML515-MBS.china.huawei.com> References: <014101d37047$63eef530$2bccdf90$@ndzh.com> In-Reply-To: <014101d37047$63eef530$2bccdf90$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927981D55E3NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 12:17:18 -0000 --_000_76CD132C3ADEF848BD84D028D243C927981D55E3NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I support the early allocation. Best regards, Jie From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Saturday, December 09, 2017 1:10 AM To: idr@ietf.org Subject: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribut= ion-05 (12/8 to 12/22) This begins a week WG call for approval of early code point allocation for= draft-ietf-eag-distribution-05.txt. You can view the specification at: https://datatracker.ietf.org/doc/draft-ietf-idr-eag-distribution/ The specification has gone through 5 revisions. There are two organization= s interested in implementing this specification. Please send in your comm= ents by 12/22. Susan Hares --_000_76CD132C3ADEF848BD84D028D243C927981D55E3NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I support the early allocation.

 

Best regards,

Jie

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Saturday, December 09, 2017 1:10 AM
To: idr@ietf.org
Subject: [Idr] Early Code Point allocation for draft-ietf-idr-eag-di= stribution-05 (12/8 to 12/22)

 

This begins a  week WG cal= l for approval of early code point allocation for draft-ietf-eag-distributi= on-05.txt. 

You can view the specification = at:

https://datatracker.ietf.org= /doc/draft-ietf-idr-eag-distribution/

 

The specification has gone thro= ugh 5 revisions.  There are two organizations interested in implementi= ng this specification.   Please send in your comments by 12/22.&n= bsp;

 

Susan Hares <= /p>

--_000_76CD132C3ADEF848BD84D028D243C927981D55E3NKGEML515MBSchi_-- From nobody Thu Dec 14 00:41:41 2017 Return-Path: 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 A921D1273E2; Thu, 14 Dec 2017 00:41:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151324088962.6230.5881485738299949839@ietfa.amsl.com> Date: Thu, 14 Dec 2017 00:41:29 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-segment-routing-te-policy-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 08:41:30 -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 : Advertising Segment Routing Policies in BGP Authors : Stefano Previdi Clarence Filsfils Paul Mattes Eric Rosen Steven Lin Filename : draft-ietf-idr-segment-routing-te-policy-01.txt Pages : 32 Date : 2017-12-13 Abstract: This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-segment-routing-te-policy/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-segment-routing-te-policy-01 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 Dec 14 07:13:29 2017 Return-Path: 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 07C31129405 for ; Thu, 14 Dec 2017 07:13:28 -0800 (PST) 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, 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=iij.ad.jp 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 nOdtIcPprQUJ for ; Thu, 14 Dec 2017 07:13:26 -0800 (PST) Received: from omgo.iij.ad.jp (mo1500.iij.ad.jp [203.180.38.48]) (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 148191293F3 for ; Thu, 14 Dec 2017 07:13:25 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:References:Subject:From:Mime-Version:Content-Type: Content-Transfer-Encoding;i=maz@iij.ad.jp;s=omgo2;t=1513264404;x=1514474004; bh=sRqjFVP6YCfIddELLSvi2hak4p/sTV09S1gRUbANYHY=; b=CWEe7dLs02jlQ9N+Ml3gjY4ybfS 3JJsLr/LGaPcTiZPeWUm76fgLLk5aDRdt00y+2jgI+FezfvbSkqK5e5JGLVh8oYvv0vBKJe2BBDZM XjsfF/uiMbF4j0TQ3BH6wVmgk7ISkcoGrD0OWJNTimlra4iKCQ/c/5SajiHS4fTccqwONMKHT5h2g 4a0NklhLeFLvJo7USpZEnCJnH9l9h2mwF8mox52dUymlJSb5AMh4cNGzlaQYC9PnoIdVxre+lJplx 8HAE6FNnMnyifDLly12MQ5VFzQMkAofdLxFLhYOcKxhDXPRWn8h0RyifnZIpZRkgfOgubXsaxY+Uc WW+Qgrw==; Received: by omgo.iij.ad.jp (of-mo1500) id vBEFDOlu011705; Fri, 15 Dec 2017 00:13:24 +0900 X-Iguazu-Qid: 33PugHQMjDHvAlA4Fk X-Iguazu-QSIG: v=1; s=0; t=1513264404; q=33PugHQMjDHvAlA4Fk; m=jvXMHIKSro4JTq8xkMRUgCDvzfYlXMFan5BgeNOZF9g= Date: Fri, 15 Dec 2017 00:13:24 +0900 (JST) Message-Id: <20171215.001324.533275110639798424.maz@iij.ad.jp> To: idr@ietf.org References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> From: Matsuzaki Yoshinobu X-PGP-Fingerprint: B69B 1B21 18C5 9C42 15CD B2BD 9B2E 4B3E 1BB5 09CA X-PGP-Fingerprint-OLD: 8E 9C EC 04 87 6B B5 0E 1B 6D 46 3B CB F7 72 CE X-PGP-Fingerprint-DSA-OLD: CCF0 9311 060F DD75 2B63 9578 7FED 4A9C 4DBF 0817 X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 15:13:28 -0000 > I would support a reasonable increase 255 or more. Agree. I might try to send funny multi lingual messages in testing environments, but probably I will use it in simple English in our network as we can not estimate language capabilities of peers' ops. ----- Matsuzaki Yoshinobu - IIJ/AS2497 INOC-DBA: 2497*629 From nobody Thu Dec 14 08:01:09 2017 Return-Path: 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 521FE127419 for ; Thu, 14 Dec 2017 08:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=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 oeCnr75mU8EW for ; Thu, 14 Dec 2017 08:01:07 -0800 (PST) Received: from mail.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) (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 A2B2B120227 for ; Thu, 14 Dec 2017 08:01:06 -0800 (PST) Received: from gir.theapt.org (gir.theapt.org [IPv6:2001:67c:12f4::2]) by mail.theapt.org (OpenSMTPD) with ESMTPSA id 467667fd (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO) for ; Thu, 14 Dec 2017 17:01:03 +0100 (CET) Date: Thu, 14 Dec 2017 17:01:02 +0100 From: Peter Hessler To: idr@ietf.org Message-ID: <20171214160102.GS37665@gir.theapt.org> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 16:01:08 -0000 The len field is 8 bits, which allows for a max of 255. If longer is desired, then we'll need a new error code point. On 2017 Dec 08 (Fri) at 23:07:55 +0000 (+0000), Thomas Mangin wrote: :Hello Job, : :I would support a reasonable increase 255 or more. : :Sincerely, : :Thomas -- If all else fails, immortality can always be assured by spectacular error. -- John Kenneth Galbraith From nobody Thu Dec 14 09:08:07 2017 Return-Path: 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 0DA96129431 for ; Thu, 14 Dec 2017 09:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oruZHCRhQwym for ; Thu, 14 Dec 2017 09:08:03 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3F1129439 for ; Thu, 14 Dec 2017 09:08:03 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 0CD4C1607FA; Thu, 14 Dec 2017 18:08:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id E810480091; Thu, 14 Dec 2017 18:08:01 +0100 (CET) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0361.001; Thu, 14 Dec 2017 18:08:01 +0100 From: To: Peter Hessler , "idr@ietf.org" Thread-Topic: [Idr] draft-snijders-idr-rfc8203bis Thread-Index: AQHTdPTFokr4nPcSgEW+/4qExFH33KNDET6g Date: Thu, 14 Dec 2017 17:08:00 +0000 Message-ID: <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> In-Reply-To: <20171214160102.GS37665@gir.theapt.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:08:05 -0000 > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler >=20 > The len field is 8 bits, which allows for a max of 255. >=20 > If longer is desired, then we'll need a new error code point. Alternatively, another field may be added after the existing "Shutdown Comm= unication" field. Either as a replacement (setting the length of the first field to zero) or = as a concatenation.=20 --Bruno =20 >=20 > On 2017 Dec 08 (Fri) at 23:07:55 +0000 (+0000), Thomas Mangin wrote: > :Hello Job, > : > :I would support a reasonable increase 255 or more. > : > :Sincerely, > : > :Thomas >=20 >=20 > -- > If all else fails, immortality can always be assured by spectacular > error. > -- John Kenneth Galbraith >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 14 09:14:54 2017 Return-Path: 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 CE22E128961 for ; Thu, 14 Dec 2017 09:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=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 XmGvQCXRFxpF for ; Thu, 14 Dec 2017 09:14:50 -0800 (PST) Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (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 224C7126C0F for ; Thu, 14 Dec 2017 09:14:50 -0800 (PST) Received: by mail-wm0-f41.google.com with SMTP id f206so12758874wmf.5 for ; Thu, 14 Dec 2017 09:14:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=scmjaPrjV9nf3moSYHpy+p4Ayqfgtw16Vv20/oGzSZo=; b=K1ieA8Z6MSt3IVJPMzHij6AeC6UPqwOpRHR3WnrZHVrpDnEFMt1+aeLpxMRu/sImJr oc2hoSFU/QexXqjO6b0qK4GrTSUtPxvepL1q5yVqkHXxdoyzH6SLXSg0GSYbbT0dutYr S01qXxBmngsQdyc3ov70Op1lXM9DJ8LoZTTLDKDkeBwQLDsiZOJjilFe4aqArKXjSQRE M0gdhWAHNBuo5l7oFHkqfCn+u3gsXPn/0mJ98WxHGkg2Y0Jw6fA9gMu9wjDIse8K9A+M FGNipZuqDk+qbvFD54ruvqW+YJ0gofD4Wz6Kqg3tTBkSd2oYimsptZa/BblYfC2wsSAp EIOA== X-Gm-Message-State: AKGB3mI9i9NA/TfThz01RrNCpKsFmUbq5A21za59Rs6n510HVdn4nO1e +j4bISXqrW4zbSaayeMOLz3VMQ== X-Google-Smtp-Source: ACJfBovytUBcs9u3bnFdULMHx7KdhO3MY6KP1Mmvp3YVCjso3ADCFOVOegxWpVBjWj0BhWMzEdom+w== X-Received: by 10.80.186.111 with SMTP id 44mr13116535eds.261.1513271688541; Thu, 14 Dec 2017 09:14:48 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id i6sm3789311eda.6.2017.12.14.09.14.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Dec 2017 09:14:47 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 0237e2f6; Thu, 14 Dec 2017 17:14:47 +0000 (UTC) Date: Thu, 14 Dec 2017 17:14:46 +0000 From: Job Snijders To: bruno.decraene@orange.com Cc: Peter Hessler , "idr@ietf.org" Message-ID: <20171214171446.GN95845@vurt.meerval.net> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:14:53 -0000 On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com wrote: > > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler > > The len field is 8 bits, which allows for a max of 255. > > > > If longer is desired, then we'll need a new error code point. > > Alternatively, another field may be added after the existing "Shutdown > Communication" field. Either as a replacement (setting the length of > the first field to zero) or as a concatenation. Bruno is right (of course, since the length field was his idea to begin with :-), there are options available to extend beyond 255 if needed. The challenge at hand is to seek consensus on what shape/size the enhancement should look like. Kind regards, Job From nobody Thu Dec 14 09:43:34 2017 Return-Path: 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 6D3D9129435 for ; Thu, 14 Dec 2017 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5Nwe5Xc4XX3j for ; Thu, 14 Dec 2017 09:43:31 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF849128616 for ; Thu, 14 Dec 2017 09:43:30 -0800 (PST) Received: from dresden.attlocal.net (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 83A481E33E; Thu, 14 Dec 2017 12:47:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jeffrey Haas In-Reply-To: <20171214171446.GN95845@vurt.meerval.net> Date: Thu, 14 Dec 2017 12:43:29 -0500 Cc: bruno.decraene@orange.com, "idr@ietf.org" , Peter Hessler Content-Transfer-Encoding: quoted-printable Message-Id: <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> To: Job Snijders X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:43:32 -0000 > On Dec 14, 2017, at 12:14 PM, Job Snijders wrote: >=20 > On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com = wrote: >>> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Peter Hessler >>> The len field is 8 bits, which allows for a max of 255. >>>=20 >>> If longer is desired, then we'll need a new error code point. >>=20 >> Alternatively, another field may be added after the existing = "Shutdown >> Communication" field. Either as a replacement (setting the length of >> the first field to zero) or as a concatenation.=20 >=20 > Bruno is right (of course, since the length field was his idea to = begin > with :-), there are options available to extend beyond 255 if needed. If the limit was 127 rather than 128, the top bit could have been used.=20= The closest thing that can be done will depend partly on what deployed = implementations do when 128 is exceed. The spec says nothing right = now... and thus you might not do anything beyond saying "up to 255 is = fine". =20 To get beyond 255, the simplest but gross one is to say "there may be a = second message after the shutdown communication field". -- Jeff (and people wonder why I'm pushy about using large "length" = fields.) From nobody Thu Dec 14 10:17:28 2017 Return-Path: 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 936041270FC for ; Thu, 14 Dec 2017 10:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zeijIIi1jvRj for ; Thu, 14 Dec 2017 10:17:25 -0800 (PST) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 47CEB12704A for ; Thu, 14 Dec 2017 10:17:25 -0800 (PST) Received: by mail-wm0-f44.google.com with SMTP id f140so13142357wmd.2 for ; Thu, 14 Dec 2017 10:17:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=7BR/G3kTPNTMBxO5Q+7FJuw6yQ3caASTgZUA51q60wU=; b=ZWRr64dr7jz5YjKGu+qhBPu6NcIcLD4IQunDb+m/GSA/cnaOFQ5h/hGZG8rOal6/mu Ht0yjsEs7J9ek/Z7PmDm9ew5nJK/bTegDTWa4qeHLO1bja0f2EFXnmA4CsaKqf6H7kww zvYhUvvMqXK4yCYFBKBmPNrtZlzJrxbuLixO75B/gLXqKJs17XcL6tDlVFs6iDM2nXo8 /ZgNY9BpqE/eXo3KJckn3LzdAQfJWKIwkLxwZxmWD+22CPGeUkJFN9z6DDtgU9RMhPeL j8BXNARAqlj1OoORXIrRLYxIZyTgVt3tNgzwREgJ6AgsAAzhUqt7CnPka71g/B+VWUJ1 9x4Q== X-Gm-Message-State: AKGB3mKadd2EK8Z8SdPlX/eYgVPXooOR950s1YgZJq/7R+mGBlRii+i3 2+R5VTXH2rt7RnKwnoIzHkDYsw== X-Google-Smtp-Source: ACJfBou6uNHhJE6HziJrKdY0iSiN+TB8wPsHpweUVYa7N107+obKFJZ9DNCRtINJIqtrylFiWWTSng== X-Received: by 10.80.209.193 with SMTP id i1mr13440431edg.107.1513275443559; Thu, 14 Dec 2017 10:17:23 -0800 (PST) Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id y3sm4182498edb.37.2017.12.14.10.17.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 14 Dec 2017 10:17:22 -0800 (PST) Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id fe9b9051; Thu, 14 Dec 2017 18:17:21 +0000 (UTC) Date: Thu, 14 Dec 2017 18:17:21 +0000 From: Job Snijders To: Jeffrey Haas Cc: bruno.decraene@orange.com, Peter Hessler , "idr@ietf.org" Message-ID: <20171214181721.GP95845@vurt.meerval.net> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:17:26 -0000 On Thu, Dec 14, 2017 at 12:43:29PM -0500, Jeffrey Haas wrote: > > On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com wrote: > >>> From: Idr idr-bounces@ietf.org On Behalf Of Peter Hessler > >>> The len field is 8 bits, which allows for a max of 255. > >>> > >>> If longer is desired, then we'll need a new error code point. > >> > >> Alternatively, another field may be added after the existing > >> "Shutdown Communication" field. Either as a replacement (setting > >> the length of the first field to zero) or as a concatenation. > > > > Bruno is right (of course, since the length field was his idea to > > begin with :-), there are options available to extend beyond 255 if > > needed. > > If the limit was 127 rather than 128, the top bit could have been > used. > > The closest thing that can be done will depend partly on what deployed > implementations do when 128 is exceed. The spec says nothing right > now... and thus you might not do anything beyond saying "up to 255 is > fine". Most of the open source implementations I'm aware of will log a message "invalid shutdown communication", and perhaps print a hexdump of that data. Since we're relatively early in the deployment cycle, I think it is feasible to upgrade the field and patch the existing implementations. > To get beyond 255, the simplest but gross one is to say "there may be > a second message after the shutdown communication field". If (and only if) we pick the route of going beyond 255, I'd consider deprecating RFC 8203 and have the new thing require the first byte to be a zero. I don't think there should be two 'shutdown communications'. > -- Jeff (and people wonder why I'm pushy about using large "length" > fields.) Not anymore! :) Kind regards, Job From nobody Thu Dec 14 11:31:44 2017 Return-Path: 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 D4A75124D6C for ; Thu, 14 Dec 2017 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 98Z-VE3-r7Tt for ; Thu, 14 Dec 2017 11:31:41 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45511200C1 for ; Thu, 14 Dec 2017 11:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2458; q=dns/txt; s=iport; t=1513279901; x=1514489501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ur5K6Vc9HB7MKGnNz5KxoFO1ChvjK0tLse3jFN+vWMw=; b=iYbu0o5vyCznxwwnxz8u5DF01eS+KcqUpCBTu3oPC3DJWg3iDP6Aeljo /xC1B/7hNDB6UFHD9vrO/GJTB9zEYa2sLHlzzTgAJ8ASwd5fMtoZlDGri qtMBK+ZoAhPfQq4qPpm8QJYUGkZLl6Pi226sAdoU8igsL8SGj6Tq8xehK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAgBm0TJa/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB50jgX2XKoIBChgLhRgChHdDFAEBAQEBAQEBAWsohSM?= =?us-ascii?q?BAQEBAgEBATg0CwUHBAIBCBEEAQEBHgkHJwsUCQgCBAENBQiKGggQq1yKYAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFg2WCDoFWhRSDLgGBMhaGHgWjJQKVH5N1lkA?= =?us-ascii?q?CERkBgToBNiKBTm8VOoIphFZ4iA+BMoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,401,1508803200"; d="scan'208";a="44190284" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 19:31:22 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBEJVM5r007671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Dec 2017 19:31:22 GMT Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Dec 2017 13:31:22 -0600 Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Thu, 14 Dec 2017 13:31:22 -0600 From: "Jakob Heitz (jheitz)" To: Job Snijders , Jeffrey Haas CC: "bruno.decraene@orange.com" , Peter Hessler , "idr@ietf.org" Thread-Topic: [Idr] draft-snijders-idr-rfc8203bis Thread-Index: AQHTcDvoN5NHVY0xNUqvjmXbgd8Js6M6Rb4AgAAxIoCACPa3AIAAErYAgAAB5ACAAAgGgIAACXeA//+t/VA= Date: Thu, 14 Dec 2017 19:31:21 +0000 Message-ID: References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> <20171214181721.GP95845@vurt.meerval.net> In-Reply-To: <20171214181721.GP95845@vurt.meerval.net> 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.154.131.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 19:31:44 -0000 The argument for Cyrillic makes sense. I have not seen any arguments for longer strings from any other language sp= eakers. 255 keeps it simple. And sufficient. Thanks, Jakob -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders Sent: Thursday, December 14, 2017 10:17 AM To: Jeffrey Haas Cc: bruno.decraene@orange.com; Peter Hessler ; idr@iet= f.org Subject: Re: [Idr] draft-snijders-idr-rfc8203bis On Thu, Dec 14, 2017 at 12:43:29PM -0500, Jeffrey Haas wrote: > > On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com wro= te: > >>> From: Idr idr-bounces@ietf.org On Behalf Of Peter Hessler > >>> The len field is 8 bits, which allows for a max of 255. > >>>=20 > >>> If longer is desired, then we'll need a new error code point. > >>=20 > >> Alternatively, another field may be added after the existing > >> "Shutdown Communication" field. Either as a replacement (setting > >> the length of the first field to zero) or as a concatenation.=20 > >=20 > > Bruno is right (of course, since the length field was his idea to > > begin with :-), there are options available to extend beyond 255 if > > needed. >=20 > If the limit was 127 rather than 128, the top bit could have been > used.=20 >=20 > The closest thing that can be done will depend partly on what deployed > implementations do when 128 is exceed. The spec says nothing right > now... and thus you might not do anything beyond saying "up to 255 is > fine". =20 Most of the open source implementations I'm aware of will log a message "invalid shutdown communication", and perhaps print a hexdump of that data. Since we're relatively early in the deployment cycle, I think it is feasible to upgrade the field and patch the existing implementations. > To get beyond 255, the simplest but gross one is to say "there may be > a second message after the shutdown communication field". If (and only if) we pick the route of going beyond 255, I'd consider deprecating RFC 8203 and have the new thing require the first byte to be a zero. I don't think there should be two 'shutdown communications'. > -- Jeff (and people wonder why I'm pushy about using large "length" > fields.) Not anymore! :) Kind regards, Job _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Thu Dec 14 13:49:22 2017 Return-Path: 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 3154B128D44 for ; Thu, 14 Dec 2017 13:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 cW-sc1dpnL5b for ; Thu, 14 Dec 2017 13:49:18 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 9ABAD12946A for ; Thu, 14 Dec 2017 13:49:16 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id t81so4894565oih.13 for ; Thu, 14 Dec 2017 13:49:16 -0800 (PST) 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=Q8XYikd6mpynVlvA0jgoojLwR792tcutZlMluYyhBSQ=; b=CJPY/6pLWdaGGZ5MqBZXeBYZ4uaA1oYKPJ31qLFcVwzFL/pIGZnFUtNNQMTnpz/GFn R/02/zAmPNJhXo1LpB2WzpSqDb5kW+4PUUa7ueLFZLqbUTj64cGrkdB0X2AaAnWMsX2M dtZtozZta1AW94lZcdMbqpYh1R8pkptu6CwVptlLgNlBhyfhwi+LcbThZrNzsbfrFCST 9bQaNVOsLDrVVjMIDxSEEAOXfgaxRlNP0pN2hqjeFhFUj4pHaxSZUmqJzRJQsiVedi90 bDBoNHrrxRM1uO/LquVZ3iTRLq6/qa5J+Z1BECXX824ChIzlKwEXu5RMK4FRZLHxVgRn 2SiA== 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=Q8XYikd6mpynVlvA0jgoojLwR792tcutZlMluYyhBSQ=; b=PhNsT7Nq/ROF9uVheUpQK8Bm6QVkcyq93Tafq0d6jXCmd2WH7A5w4GVh3nW1axlT5K ToKRNBWMHhJMxrv9zGpxpFyGhj/hYIY/6K3T+mI56Tv4Dof1MfLs2PPQxgTQfl4E4WwY zxo4pFxkqtjFqKS9iUjPqCscFVImbb7kqMClQLTq4Ow/P72alugTGgbZFtSNKNSScssq N3gqS74veItphXIBUIGLjAydJWGyV2pZAi3IaRuQ7FlcbqYMe+wJPxDohf/pFO0mhlPO QP8RWHsWo7rNr8z1wAnjHg7y3h6CcOQKYW1lrSmSj7or73KOGWeO/zv4A8HBkj81+ceP 3CHg== X-Gm-Message-State: AKGB3mL10u1DiA7dR+IfOjpNwlM4BmZee5+DM57aOnbL9R5DzcrSquWM JWRTcukBfGeWwkU4K7PCAC8= X-Google-Smtp-Source: ACJfBosetx8wA/It3GVbgIpKsdNKxpOkNXrJYcN5tJtKflan0oMiQSt0mcNW7rJWgp9FD1M/QfEQAA== X-Received: by 10.202.4.209 with SMTP id 200mr5126459oie.43.1513288155962; Thu, 14 Dec 2017 13:49:15 -0800 (PST) Received: from [100.65.101.83] ([206.16.17.196]) by smtp.gmail.com with ESMTPSA id u2sm2429345otf.66.2017.12.14.13.49.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 13:49:14 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.29.0.171205 Date: Thu, 14 Dec 2017 13:49:13 -0800 From: Jeff Tantsura To: "Jakob Heitz (jheitz)" , Job Snijders , Jeffrey Haas CC: "bruno.decraene@orange.com" , Peter Hessler , "idr@ietf.org" Message-ID: <5B1FE918-14D7-4C8B-ACEE-488323D9A051@gmail.com> Thread-Topic: [Idr] draft-snijders-idr-rfc8203bis References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> <20171214181721.GP95845@vurt.meerval.net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:49:20 -0000 +1 Cheers, Jeff -----Original Message----- From: Idr on behalf of "Jakob Heitz (jheitz)" Date: Thursday, December 14, 2017 at 11:31 To: Job Snijders , Jeffrey Haas Cc: "bruno.decraene@orange.com" , Peter Hessler , "idr@ietf.org" Subject: Re: [Idr] draft-snijders-idr-rfc8203bis The argument for Cyrillic makes sense. I have not seen any arguments for longer strings from any other language speakers. 255 keeps it simple. And sufficient. Thanks, Jakob -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Job Snijders Sent: Thursday, December 14, 2017 10:17 AM To: Jeffrey Haas Cc: bruno.decraene@orange.com; Peter Hessler ; idr@ietf.org Subject: Re: [Idr] draft-snijders-idr-rfc8203bis On Thu, Dec 14, 2017 at 12:43:29PM -0500, Jeffrey Haas wrote: > > On Thu, Dec 14, 2017 at 05:08:00PM +0000, bruno.decraene@orange.com wrote: > >>> From: Idr idr-bounces@ietf.org On Behalf Of Peter Hessler > >>> The len field is 8 bits, which allows for a max of 255. > >>> > >>> If longer is desired, then we'll need a new error code point. > >> > >> Alternatively, another field may be added after the existing > >> "Shutdown Communication" field. Either as a replacement (setting > >> the length of the first field to zero) or as a concatenation. > > > > Bruno is right (of course, since the length field was his idea to > > begin with :-), there are options available to extend beyond 255 if > > needed. > > If the limit was 127 rather than 128, the top bit could have been > used. > > The closest thing that can be done will depend partly on what deployed > implementations do when 128 is exceed. The spec says nothing right > now... and thus you might not do anything beyond saying "up to 255 is > fine". Most of the open source implementations I'm aware of will log a message "invalid shutdown communication", and perhaps print a hexdump of that data. Since we're relatively early in the deployment cycle, I think it is feasible to upgrade the field and patch the existing implementations. > To get beyond 255, the simplest but gross one is to say "there may be > a second message after the shutdown communication field". If (and only if) we pick the route of going beyond 255, I'd consider deprecating RFC 8203 and have the new thing require the first byte to be a zero. I don't think there should be two 'shutdown communications'. > -- Jeff (and people wonder why I'm pushy about using large "length" > fields.) Not anymore! :) Kind regards, Job _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Mon Dec 18 04:05:16 2017 Return-Path: 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 09238129C53; Mon, 18 Dec 2017 04:05:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151359871101.28870.3678063106470253801@ietfa.amsl.com> Date: Mon, 18 Dec 2017 04:05:11 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 12:05:11 -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 : Signalling ERLD using BGP-LS Authors : Gunter Van de Velde Wim Henderickx Matthew Bocci Keyur Patel Filename : draft-ietf-idr-bgp-ls-segment-routing-rld-01.txt Pages : 6 Date : 2017-12-18 Abstract: This document defines the attributes to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node or link to a centralised controller (PCE/SDN). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-01 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-rld-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-01 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 Dec 20 00:23:14 2017 Return-Path: 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 4CFCD1200C1; Wed, 20 Dec 2017 00:23:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151375818826.2596.2257909983897406763@ietfa.amsl.com> Date: Wed, 20 Dec 2017 00:23:08 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-14.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 08:23:08 -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 : BGP-LS extensions for Segment Routing BGP Egress Peer Engineering Authors : Stefano Previdi Clarence Filsfils Keyur Patel Saikat Ray Jie Dong Filename : draft-ietf-idr-bgpls-segment-routing-epe-14.txt Pages : 21 Date : 2017-12-19 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-14 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-segment-routing-epe-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-segment-routing-epe-14 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 Dec 20 01:30:03 2017 Return-Path: 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 3738012D94A; Wed, 20 Dec 2017 01:29:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151376219717.2637.11384715606984665204@ietfa.amsl.com> Date: Wed, 20 Dec 2017 01:29:57 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:29:57 -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 : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-03.txt Pages : 12 Date : 2017-12-20 Abstract: This document defines a new extended community known as flowspec redirect-to-indirection-id. This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to find the corresponding next-hop information within a indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the selected redirection path itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-path-redirect-03 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 Dec 20 01:32:52 2017 Return-Path: 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 AEDD212D962; Wed, 20 Dec 2017 01:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ddNZ3GaPcc4b; Wed, 20 Dec 2017 01:32:48 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A842012D946; Wed, 20 Dec 2017 01:32:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3176; q=dns/txt; s=iport; t=1513762368; x=1514971968; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=4CKE3cn+q9Xa4ReN4n7vTAl3eZGgfm6EUf/9alwcfns=; b=iA4AptO9tfi+pOd96dItyy/bcyYgGCs2jz3QVQY3YKJ4Jv6ouPqK3Bqo GkbhmqDJEVSHcKLtjtm+TLDYXedG4FDcBAkbGfA+T2chPeEMQZ1YvNE57 b+fBCj6N5siVBYxYQE/zoK+skvbgvJrHYXTRzE9g8UkZHcy+Bx6DD4MS+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7AQC0LTpa/4gNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB44gjw+CApclghUKGA2FFgKFET8YAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBBgE4NBcGARkBAwEBHwkuCxQDBgkBBAESCIojEKZPinEBAQEBAQEBAQIBA?= =?us-ascii?q?QEBAQEBAQEBHoN/ghKBVoFphlsBAReHTwWKVZhvAod+g3GJNIIgZYEahBaLS40?= =?us-ascii?q?diTECERkBgToBHzmBT28VGCSCKQmETniJUYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,431,1508803200"; d="scan'208";a="46517896" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2017 09:32:47 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vBK9WlG7001745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Dec 2017 09:32:47 GMT Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 20 Dec 2017 03:32:47 -0600 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.1320.000; Wed, 20 Dec 2017 03:32:46 -0600 From: "Ketan Talaulikar (ketant)" To: "idr@ietf.org" , "idr-chairs@ietf.org" Thread-Topic: Awaiting Write-up : draft-ietf-idr-bgpls-segment-routing-epe-14 Thread-Index: AdN5dXvDORVMceI8RvSnIw3T2Q+vww== Date: Wed, 20 Dec 2017 09:32:46 +0000 Message-ID: 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.54.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Idr] Awaiting Write-up : draft-ietf-idr-bgpls-segment-routing-epe-14 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:32:50 -0000 Hello, This is just a refresh of the draft without any content change that I've su= bmitted (in taking over from Stefano).=20 It has already been through the WGLC and needs to move forward to IESG. I b= elieve it is awaiting Shepherd write-up to progress further? While this is standards track, its companion use-case draft draft-ietf-spri= ng-segment-routing-central-epe is already with IESG for publication. Would = appreciate if the WG chairs could help progress this since it has been in t= his state for a very long time now. Thanks, Ketan -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: 20 December 2017 13:53 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-segment-routing-epe-14.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP-LS extensions for Segment Routing BGP Egress = Peer Engineering Authors : Stefano Previdi Clarence Filsfils Keyur Patel Saikat Ray Jie Dong Filename : draft-ietf-idr-bgpls-segment-routing-epe-14.txt Pages : 21 Date : 2017-12-19 Abstract: Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node of the SR domain. The Segment Routing architecture can be directly applied to the MPLS dataplane with no change on the forwarding plane. It requires minor extension to the existing link-state routing protocols. This document outline a BGP-LS extension for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-segment-routing-epe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgpls-segment-routing-epe-14 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-segment-routing-= epe-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgpls-segment-routing-ep= e-14 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Dec 20 01:41:11 2017 Return-Path: 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 7602412D835 for ; Wed, 20 Dec 2017 01:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J72UKm_-X_ga for ; Wed, 20 Dec 2017 01:41:08 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0105.outbound.protection.outlook.com [104.47.1.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CD8126C22 for ; Wed, 20 Dec 2017 01:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=d1gYhp1f6CAoP7haCVuaS7fAeIxAZ0522K6RXVBl8IE=; b=ASloz0mt0ZjFwOXPRit762w2ZWoKhCDhSu2NckG4J5oAmrnWDdDn8jCTAkfCqVuT3O015kyBFXK45zhQxX/GyBJDILbXBenQWgAH+LE7qBmDy5UABHlJm8OZjKsOen7H9GZhRTjhmGfagAg36Bl63vnOEiijpdef2WAyXJjSVNo= Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com (10.168.91.145) by HE1PR0701MB2843.eurprd07.prod.outlook.com (10.168.91.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Wed, 20 Dec 2017 09:41:05 +0000 Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::55af:7f56:2056:e253]) by HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::55af:7f56:2056:e253%17]) with mapi id 15.20.0345.013; Wed, 20 Dec 2017 09:41:05 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt Thread-Index: AQHTeXUwHkb+QDi3lUmDBelonxx+mqNL+HJg Date: Wed, 20 Dec 2017 09:41:05 +0000 Message-ID: References: <151376219717.2637.11384715606984665204@ietfa.amsl.com> In-Reply-To: <151376219717.2637.11384715606984665204@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1810:4d67:a00:c94f:8533:77ca:4630] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2843; 6:9HavHklko54YBCylO7fMlo/u2llRxPquPbr7Kvk391Lbw7LaEQpWZlxGk2jJveVeSjcHMtlJ/YUIZDZRtXfV7wyg9MXNe3B+v5xlrDwcvB8qgGAKILzQ+qhQevZ2bVPXhJvpDUAKkUu2/qO8sdh6SPwfnbTw5p9B55QG8v2IpHxRY+M42LkScN5ZMUxMwnggVj2Lf1+cNxvOdYHvyD/In/t6Zv5Yokrjj/u4rt27kj7nQZxzaWKZbmZslDd3OP7u7/Ujj5qTr3KOTbzDFhTIf9K8df1hui/hlTKe0bPFv4ZGc5eH3nPfjISA1RV1K4KL9Agnv2YIY3LbGOe1Q2dWxqwjRFje5Q8eRadQQZqO0fU=; 5:nUV1nkA/rGoBKwppp4CiGkDygibJHgXPg+klSZ7l1axlssUyDSyZhA7nKRhzwTW8FMSEunjbW+NUF/7tmi6YRcsk2Ltsp6s84RbkD2fCMSd+f571mEH6Yl2tEpfGePrcYEsuMPwd8h/g5ABM6HKzP/SRw5+uGOGhJC0tHjeBQR8=; 24:d7CDcAEkKaKuSpiS42cqHh2Xko9nocS+8nqsMwpDOkhQ97dgluxS1xKp85+9rGUqid6Qqle53BFlrckK5y5w+SG78lwJSv3nLzXwo+hgfKU=; 7:slctgq4/p3DxV09BnQ0PPunCIAYV9fLfkPBwGE9k8KA2HbUvC89JWBrlytRMviA8X7Qg+p3cM6aEeAF0u5Zb8FAYv4+roHbHKOQmj9PbwSAZaZixYga5gN53d9DETwouthCqhdYQ9/5yFdhuuhwCZuokTWsDmVUWtO/wmIx3b1QqG/PGgxEjQd10HfLmhGw3Lyu3MC1FBhJC+1uobxH8rUobRRPPOQPljpA6+DduDKakPmqy4jJO7O3ZwC8PEFjx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7fcc5d16-30ca-49d4-026e-08d5478dca61 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:HE1PR0701MB2843; x-ms-traffictypediagnostic: HE1PR0701MB2843: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(806099)(3002001)(10201501046)(6055026)(6041268)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB2843; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2843; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(346002)(376002)(366004)(377424004)(189003)(199004)(13464003)(74316002)(305945005)(102836003)(7736002)(97736004)(25786009)(4001150100001)(966005)(6116002)(5660300001)(105586002)(33656002)(3280700002)(478600001)(3660700001)(5250100002)(106356001)(230783001)(6506007)(2501003)(2906002)(2351001)(53546011)(99286004)(316002)(229853002)(2900100001)(68736007)(86362001)(8936002)(6246003)(7696005)(76176011)(6436002)(14454004)(55016002)(9686003)(81156014)(81166006)(6306002)(1730700003)(8676002)(2950100002)(6916009)(5640700003)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2843; H:HE1PR0701MB2843.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: PZKkKRSzBKz1U+sPe4DEMdbPC/bfXE3cgIj0mh1BE8kk9D0kvaptQZHrvXllrTM34mNMdbJqGqz1uBSesxWcZQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fcc5d16-30ca-49d4-026e-08d5478dca61 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 09:41:05.2234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2843 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 09:41:10 -0000 All, This draft has been simplified and removed some clutter. Authors believe th= e draft to have reached stable content. The flowspec indirection-ids included are: Type0 - localized indirection, T= ype 1&2 - node SID (index & global), Type 3&4 - binding SID (index&global) = and Type 5 - global tunnel-id. G/=20 -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: Wednesday, December 20, 2017 10:30 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-03.txt Pages : 12 Date : 2017-12-20 Abstract: This document defines a new extended community known as flowspec redirect-to-indirection-id. This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to find the corresponding next-hop information within a indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the selected redirection path itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect= -03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-flowspec-path-redirect-0= 3 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Dec 20 07:42:38 2017 Return-Path: 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 D14871270A7 for ; Wed, 20 Dec 2017 07:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 eNCZ-Ej4maj0 for ; Wed, 20 Dec 2017 07:42:35 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 07AD9128959 for ; Wed, 20 Dec 2017 07:42:34 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Van De Velde, Gunter \(Nokia - BE/Antwerp\)'" , References: <151376219717.2637.11384715606984665204@ietfa.amsl.com> In-Reply-To: Date: Wed, 20 Dec 2017 10:42:31 -0500 Message-ID: <00cc01d379a9$2643fc60$72cbf520$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJdyE8a0324xr0Dty+YUSPEuYf3DgJP+XxpoiVBzfA= X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 15:42:37 -0000 Gunter: Are you looking for a WG LC for this draft? Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Wednesday, December 20, 2017 4:41 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt All, This draft has been simplified and removed some clutter. Authors believe the draft to have reached stable content. The flowspec indirection-ids included are: Type0 - localized indirection, Type 1&2 - node SID (index & global), Type 3&4 - binding SID (index&global) and Type 5 - global tunnel-id. G/ -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, December 20, 2017 10:30 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt 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 : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-03.txt Pages : 12 Date : 2017-12-20 Abstract: This document defines a new extended community known as flowspec redirect-to-indirection-id. This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to find the corresponding next-hop information within a indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the selected redirection path itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect- 03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-path-redirect-03 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/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Dec 20 07:52:05 2017 Return-Path: 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 3899C126C25 for ; Wed, 20 Dec 2017 07:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFMtIE1iJ5Bb for ; Wed, 20 Dec 2017 07:52:00 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0100.outbound.protection.outlook.com [104.47.0.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E181200FC for ; Wed, 20 Dec 2017 07:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RRmib7HEEPP96Sj4K+Ztt004VNDw7JhEAb6/ACKKWUM=; b=CWF/gc3fLAb6mVaI93ezHpJX8+V9UXjpuWl/jy9olcVFCTkPqfu+Ts020o3FBIdQvN+Dcf0GuwSKzNG2EWhivUEdE88ZKQcmI8B826Cxt2WsFb948MM9PahS6QQNZCEuLcatGrG8yoYrdAKdWQ31ChI8O/aw2QcqrI0Vq1NFDr4= Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com (10.168.91.145) by HE1PR0701MB2841.eurprd07.prod.outlook.com (10.168.91.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Wed, 20 Dec 2017 15:51:57 +0000 Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::55af:7f56:2056:e253]) by HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::55af:7f56:2056:e253%17]) with mapi id 15.20.0345.013; Wed, 20 Dec 2017 15:51:56 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt Thread-Index: AQHTeXUwHkb+QDi3lUmDBelonxx+mqNL+HJggABm7oCAABNlAA== Date: Wed, 20 Dec 2017 15:51:56 +0000 Message-ID: References: <151376219717.2637.11384715606984665204@ietfa.amsl.com> <00cc01d379a9$2643fc60$72cbf520$@ndzh.com> In-Reply-To: <00cc01d379a9$2643fc60$72cbf520$@ndzh.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [2a02:a03f:4e53:1200:4c68:8a3b:ae6:fd1a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2841; 6:mgEI7wuDOq6NlVAE7kyFkxp+DFPfsAT4k5Lh09E9pSQBmanBTzBGw6+L3fS6BAokxVcQtQNsr4u9Z5BsMpyWy5hpXcWlp/7/JS5+ocLr1Ugs8Itn0dWrUfTE+Ad2GcZTxdEgOizCqKMTmsRbMgVIYzMgLSk1zsDZHQDmiQ8cOf8V9OmS/gYVKd6xTBkjkfk/3WdXXdLWktlKbMyg62SKLOck++CXcAHmG2FJze4zT9yxw8j7gzln1efcr/xJH8g6XnfY/jwO4mhYYrrS3wOfJy1A/GhCz153/oqyythRg6mpfh0MM3c4L2euCWxRFkkKdE1L71+GrIheki4eHERqAT7ctXlHIgTcts3CSzo0aO4=; 5:ESH4Av0IqDUh7DSVL5ge3RuBt8qS5o+bPMqHA09ZW4XVZi0vnKt+4CH0sZL9DC8sCxpVg0NBzLTX2DwtOTHbKR8W/Hw+oX4aAmSLEtketyCjBY4I0ZMpikOLjgaf9lXHIhPSxFjcHAmXuIB1/sPm6Tdyp9kaZuvVhvCh97PYMyM=; 24:Jl6fb4hX6IsmroqGNji5T9/P9NWyUjxCDpP9uLCcRG1F32XsDfofgGPV/0q3vzDfqr7mnj+zGCNOc6dXdq8iYv8OTE6lXms1MQXvXiMYObI=; 7:eKUFt6i3403P0KlvntawZUxjDAEulmFYHV8k8h8RImEqQQJXWtGpH944Pc64tLRedm+bWhlcxejOD4dtKJDW+Zq47+p3BvQQ8aOIWH0iJRPubB8Vdg2MW6xwsDbp7lNnOJa6ozOtOrCXmvWylxU5DqbmwgV+2L46T9/Rn5OBK9lG2bx3SvUPJKoyGMVsTA9uTu4LNM9LDgtj5O1CHROmXF1TSq0ekEHvjqJWQpJsESZWCJqugfZBJMW0prdL9D8Q x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: deb179d4-7507-4ce7-66e2-08d547c19958 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:HE1PR0701MB2841; x-ms-traffictypediagnostic: HE1PR0701MB2841: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(11241501184)(806099)(93006095)(93001095)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0701MB2841; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0701MB2841; x-forefront-prvs: 0527DFA348 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(39380400002)(396003)(346002)(24454002)(199004)(377424004)(189003)(13464003)(36756003)(229853002)(83716003)(5250100002)(478600001)(86362001)(97736004)(2501003)(53546011)(99286004)(110136005)(6506007)(68736007)(230783001)(7736002)(2950100002)(76176011)(8936002)(316002)(305945005)(5660300001)(4001150100001)(81166006)(6486002)(25786009)(81156014)(82746002)(6246003)(6116002)(8676002)(6306002)(102836003)(6436002)(33656002)(966005)(3280700002)(6512007)(3660700001)(14454004)(2906002)(2900100001)(106356001)(105586002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2841; H:HE1PR0701MB2843.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HyNnXboJLZ8ayvOW9vuLu0uCGD9pmuteQv3BM9usROYVImk4rrsk/q/pR1m1D14LbtxZuHaEuzdx/GwgzO9jBw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <0449981E433C4945AC72FCED7CC8415C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: deb179d4-7507-4ce7-66e2-08d547c19958 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2017 15:51:56.9292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2841 Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 15:52:02 -0000 SGkgU3VlLA0KDQpUaGFua3MuIElmIGluIHRoZSBuZXh0IGZldyB3ZWVrcyBubyB0ZWNobmljYWwg bWlzdGFrZXMgYXJlIGRpc2NvdmVyZWQsIHRoZW4gbWF5YmUgaXQgaXMgcmVhZHkgZm9yIFdHTEMu IFRpbWUgd2lsbCBwcm92aWRlIGZlZWRiYWNrIGluIElEUiBXRy4NCiANCldoYXQgc2VlbXMgYSBt b3JlIHByZXNzaW5nIG1hdHRlciBhdCB0aGlzIHN0YWdlIHdvdWxkIGJlIHRvIGdldCBJQU5BIGNv ZGUtcG9pbnRzLiBOb3Qgc3VyZSB3aGF0IGlzIHRoZSBiZXN0IHByb2Nlc3MgdG8gZ2V0IHRob3Nl PyANCg0KRy8NCg0KT24gMjAvMTIvMjAxNywgMTY6NDIsICJTdXNhbiBIYXJlcyIgPHNoYXJlc0Bu ZHpoLmNvbT4gd3JvdGU6DQoNCiAgICBHdW50ZXI6DQogICAgDQogICAgQXJlIHlvdSBsb29raW5n IGZvciBhIFdHIExDIGZvciB0aGlzIGRyYWZ0PyANCiAgICANCiAgICBTdWUgDQogICAgDQogICAg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBJZHIgW21haWx0bzppZHItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZhbiBEZSBWZWxkZSwgR3VudGVyDQogICAgKE5v a2lhIC0gQkUvQW50d2VycCkNCiAgICBTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDIwLCAyMDE3 IDQ6NDEgQU0NCiAgICBUbzogaWRyQGlldGYub3JnDQogICAgU3ViamVjdDogUmU6IFtJZHJdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDMudHh0DQog ICAgDQogICAgQWxsLA0KICAgIA0KICAgIFRoaXMgZHJhZnQgaGFzIGJlZW4gc2ltcGxpZmllZCBh bmQgcmVtb3ZlZCBzb21lIGNsdXR0ZXIuIEF1dGhvcnMgYmVsaWV2ZSB0aGUNCiAgICBkcmFmdCB0 byBoYXZlIHJlYWNoZWQgc3RhYmxlIGNvbnRlbnQuDQogICAgDQogICAgVGhlIGZsb3dzcGVjIGlu ZGlyZWN0aW9uLWlkcyBpbmNsdWRlZCBhcmU6IFR5cGUwIC0gbG9jYWxpemVkIGluZGlyZWN0aW9u LA0KICAgIFR5cGUgMSYyIC0gbm9kZSBTSUQgKGluZGV4ICYgZ2xvYmFsKSwgVHlwZSAzJjQgLSBi aW5kaW5nIFNJRCAoaW5kZXgmZ2xvYmFsKQ0KICAgIGFuZCBUeXBlIDUgLSBnbG9iYWwgdHVubmVs LWlkLg0KICAgIA0KICAgIEcvIA0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQogICAgRnJvbTogSWRyIFttYWlsdG86aWRyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KICAgIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgIFNlbnQ6IFdlZG5lc2Rh eSwgRGVjZW1iZXIgMjAsIDIwMTcgMTA6MzANCiAgICBUbzogaS1kLWFubm91bmNlQGlldGYub3Jn DQogICAgQ2M6IGlkckBpZXRmLm9yZw0KICAgIFN1YmplY3Q6IFtJZHJdIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDMudHh0DQogICAgDQogICAgDQog ICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzDQogICAgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgSW50ZXItRG9tYWluIFJvdXRpbmcgV0cgb2YgdGhlIElFVEYuDQogICAgDQog ICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBGbG93c3BlYyBJbmRpcmVjdGlvbi1pZCBSZWRp cmVjdA0KICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogR3VudGVyIFZhbiBkZSBWZWxkZQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgS2V5dXIgUGF0ZWwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFpoZW5iaW4gTGkNCiAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1pZHItZmxvd3NwZWMtcGF0aC1yZWRpcmVjdC0wMy50eHQNCiAgICAJUGFnZXMgICAgICAg ICAgIDogMTINCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0yMA0KICAgIA0KICAgIEFi c3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG5ldyBleHRlbmRlZCBjb21t dW5pdHkga25vd24gYXMgZmxvd3NwZWMNCiAgICAgICByZWRpcmVjdC10by1pbmRpcmVjdGlvbi1p ZC4gIFRoaXMgZXh0ZW5kZWQgY29tbXVuaXR5IHRyaWdnZXJzDQogICAgICAgYWR2YW5jZWQgcmVk aXJlY3Rpb24gY2FwYWJpbGl0aWVzIHRvIGZsb3dzcGVjIGNsaWVudHMuICBXaGVuDQogICAgICAg YWN0aXZhdGVkLCB0aGlzIGZsb3dzcGVjIGV4dGVuZGVkIGNvbW11bml0eSBpcyB1c2VkIGJ5IGEg Zmxvd3NwZWMNCiAgICAgICBjbGllbnQgdG8gZmluZCB0aGUgY29ycmVzcG9uZGluZyBuZXh0LWhv cCBpbmZvcm1hdGlvbiB3aXRoaW4gYQ0KICAgICAgIGluZGlyZWN0aW9uLWlkIG1hcHBpbmcgdGFi bGUuDQogICAgDQogICAgICAgVGhlIGZ1bmN0aW9uYWxpdHkgZGV0YWlsZWQgaW4gdGhpcyBkb2N1 bWVudCBhbGxvd3MgYSBuZXR3b3JrDQogICAgICAgY29udHJvbGxlciB0byBkZWNvdXBsZSB0aGUg QkdQIGZsb3dzcGVjIHJlZGlyZWN0aW9uIGluc3RydWN0aW9uIGZyb20NCiAgICAgICB0aGUgc2Vs ZWN0ZWQgcmVkaXJlY3Rpb24gcGF0aCBpdHNlbGYuDQogICAgDQogICAgDQogICAgDQogICAgVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pZHItZmxvd3NwZWMtcGF0 aC1yZWRpcmVjdC8NCiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt aWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDMNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtDQog ICAgMDMNCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp bGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtaWRyLWZsb3dzcGVjLXBhdGgtcmVkaXJlY3QtMDMNCiAgICANCiAgICANCiAgICBQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIElkciBtYWlsaW5nIGxpc3QNCiAgICBJZHJA aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0K ICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgSWRyIG1haWxpbmcgbGlzdA0KICAgIElkckBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQogICAgDQogICAgDQoNCg== From nobody Wed Dec 20 08:01:53 2017 Return-Path: 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 8AC0D129511 for ; Wed, 20 Dec 2017 08:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 2exOZy22royO for ; Wed, 20 Dec 2017 08:01:50 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D38531200FC for ; Wed, 20 Dec 2017 08:01:49 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.58.28; From: "Susan Hares" To: "'Van De Velde, Gunter \(Nokia - BE/Antwerp\)'" , References: <151376219717.2637.11384715606984665204@ietfa.amsl.com> <00cc01d379a9$2643fc60$72cbf520$@ndzh.com> In-Reply-To: Date: Wed, 20 Dec 2017 11:01:46 -0500 Message-ID: <00f601d379ab$d675a8c0$8360fa40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJdyE8a0324xr0Dty+YUSPEuYf3DgJP+XxpAqLcgQ8BeZHBMqIEY7rA X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 16:01:51 -0000 I do a WG call for early adoption. Shall I start this today? Sue Hares -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Wednesday, December 20, 2017 10:52 AM To: Susan Hares; idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt Hi Sue, Thanks. If in the next few weeks no technical mistakes are discovered, then maybe it is ready for WGLC. Time will provide feedback in IDR WG. What seems a more pressing matter at this stage would be to get IANA code-points. Not sure what is the best process to get those? G/ On 20/12/2017, 16:42, "Susan Hares" wrote: Gunter: Are you looking for a WG LC for this draft? Sue -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) Sent: Wednesday, December 20, 2017 4:41 AM To: idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt All, This draft has been simplified and removed some clutter. Authors believe the draft to have reached stable content. The flowspec indirection-ids included are: Type0 - localized indirection, Type 1&2 - node SID (index & global), Type 3&4 - binding SID (index&global) and Type 5 - global tunnel-id. G/ -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Wednesday, December 20, 2017 10:30 To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-path-redirect-03.txt 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 : Flowspec Indirection-id Redirect Authors : Gunter Van de Velde Keyur Patel Zhenbin Li Filename : draft-ietf-idr-flowspec-path-redirect-03.txt Pages : 12 Date : 2017-12-20 Abstract: This document defines a new extended community known as flowspec redirect-to-indirection-id. This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to find the corresponding next-hop information within a indirection-id mapping table. The functionality detailed in this document allows a network controller to decouple the BGP flowspec redirection instruction from the selected redirection path itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-flowspec-path-redirect-03 https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect- 03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-path-redirect-03 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/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Dec 20 09:14:30 2017 Return-Path: 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 2DB19129C59 for ; Wed, 20 Dec 2017 09:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 l4sgj3y7lEQo for ; Wed, 20 Dec 2017 09:14:27 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6921270A3 for ; Wed, 20 Dec 2017 09:14:27 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9A1131E35A; Wed, 20 Dec 2017 12:18:32 -0500 (EST) Date: Wed, 20 Dec 2017 12:18:32 -0500 From: Jeffrey Haas To: Susan Hares Cc: idr@ietf.org Message-ID: <20171220171832.GF8708@pfrc.org> References: <014101d37047$63eef530$2bccdf90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <014101d37047$63eef530$2bccdf90$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] Early Code Point allocation for draft-ietf-idr-eag-distribution-05 (12/8 to 12/22) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 17:14:28 -0000 On Fri, Dec 08, 2017 at 12:10:03PM -0500, Susan Hares wrote: > This begins a week WG call for approval of early code point allocation for > draft-ietf-eag-distribution-05.txt. I support the early code point allocation. -- Jeff From nobody Wed Dec 20 09:23:42 2017 Return-Path: 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 A80E01270A3 for ; Wed, 20 Dec 2017 09:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 jVEc9z0jD8aU for ; Wed, 20 Dec 2017 09:23:39 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 540941241F3 for ; Wed, 20 Dec 2017 09:23:39 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id CB2321E35A; Wed, 20 Dec 2017 12:27:44 -0500 (EST) Date: Wed, 20 Dec 2017 12:27:44 -0500 From: Jeffrey Haas To: Job Snijders Cc: bruno.decraene@orange.com, Peter Hessler , "idr@ietf.org" Message-ID: <20171220172744.GG8708@pfrc.org> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> <20171214181721.GP95845@vurt.meerval.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171214181721.GP95845@vurt.meerval.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 17:23:41 -0000 On Thu, Dec 14, 2017 at 06:17:21PM +0000, Job Snijders wrote: > > To get beyond 255, the simplest but gross one is to say "there may be > > a second message after the shutdown communication field". > > If (and only if) we pick the route of going beyond 255, I'd consider > deprecating RFC 8203 and have the new thing require the first byte to be > a zero. I don't think there should be two 'shutdown communications'. IMO, there's enough support for "255 is good enough" that a -bis is warranted with that as a goal. That said, a -bis document is typically the original document with the modifications plus an appendix explaining the change. You might want to consider re-spinning this doc in that format before asking for adoption (which I would support). -- Jeff From nobody Wed Dec 20 09:25:20 2017 Return-Path: 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 3617F129C6F for ; Wed, 20 Dec 2017 09:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ltETe1uaOXbJ for ; Wed, 20 Dec 2017 09:25:17 -0800 (PST) Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (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 D16C11241F3 for ; Wed, 20 Dec 2017 09:25:17 -0800 (PST) Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eRi7J-0001FB-DR (job@us.ntt.net) for idr@ietf.org; Wed, 20 Dec 2017 17:25:17 +0000 Received: by mail-ot0-f177.google.com with SMTP id b56so5961109otd.10 for ; Wed, 20 Dec 2017 09:25:17 -0800 (PST) X-Gm-Message-State: AKGB3mKAiC+/2XR5LxVCQo1mzBdOr2Ojq/G2BMT55xVr7shRu3Ikp8Fs XYNBM0D19Zrd+sPcXEzPkRaZ2VJDZNPQIf/mOlZORg== X-Google-Smtp-Source: ACJfBovUEjOKctawqoYhBaULnS6kWtgzgH4+kgfkYUIhufFz1djiAHiWZdPXKq+wjQpXI1MVrOnUScpkRW01H2UGklA= X-Received: by 10.157.54.250 with SMTP id s55mr1809498otd.397.1513790716494; Wed, 20 Dec 2017 09:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.23.140 with HTTP; Wed, 20 Dec 2017 09:25:15 -0800 (PST) X-Originating-IP: [2001:67c:208c:10:c10b:ff13:83fd:8c10] In-Reply-To: <20171220172744.GG8708@pfrc.org> References: <20171208154735.GH61799@vurt.meerval.net> <3238CB61-EDB3-4C5D-813D-AC19362AB2CF@puck.nether.net> <20171214160102.GS37665@gir.theapt.org> <13067_1513271281_5A32AFF1_13067_469_1_53C29892C857584299CBF5D05346208A479212FF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20171214171446.GN95845@vurt.meerval.net> <4D213F3F-DAC8-4F18-ABA6-517A8213BFA7@pfrc.org> <20171214181721.GP95845@vurt.meerval.net> <20171220172744.GG8708@pfrc.org> From: Job Snijders Date: Wed, 20 Dec 2017 18:25:15 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jeffrey Haas Cc: Job Snijders , Bruno Decraene , Peter Hessler , "idr@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Idr] draft-snijders-idr-rfc8203bis X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 17:25:19 -0000 On Wed, Dec 20, 2017 at 6:27 PM, Jeffrey Haas wrote: > On Thu, Dec 14, 2017 at 06:17:21PM +0000, Job Snijders wrote: >> > To get beyond 255, the simplest but gross one is to say "there may be >> > a second message after the shutdown communication field". >> >> If (and only if) we pick the route of going beyond 255, I'd consider >> deprecating RFC 8203 and have the new thing require the first byte to be >> a zero. I don't think there should be two 'shutdown communications'. > > IMO, there's enough support for "255 is good enough" that a -bis is > warranted with that as a goal. > > That said, a -bis document is typically the original document with the > modifications plus an appendix explaining the change. You might want to > consider re-spinning this doc in that format before asking for adoption > (which I would support). I'll do that. Thank you for the feedback Kind regards, Job From nobody Thu Dec 21 09:08:54 2017 Return-Path: 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 BAA1812D779; Thu, 21 Dec 2017 09:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.018 X-Spam-Level: X-Spam-Status: No, score=-3.018 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=outlook.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 Y-_WaxRzK4hf; Thu, 21 Dec 2017 09:08:49 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-oln040092072087.outbound.protection.outlook.com [40.92.72.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B979127876; Thu, 21 Dec 2017 09:08:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nTl0c+DgkBUDETMi9iObsS6prb8UGhXkpNEvQw0ic+c=; b=fI+bJZAAMh3rUWom0Y/yyWpb9g5OdE1al5S/I+qTvXVSyH65AvCjgnr3F987SsgSdWoikuRisP3Zb9Sktu6M9uByZ+gYQMeYJQuOfEqSzd2FQXlIr3pER8qqqB9Puh/9lOCbZ7AkJo04aSDYVakwseumaWuyOF0JrwIhxTNHnpoTzT0HAiRicUaVfD8z3jYqHa+bkFLlwLBncxee4tQR16LWw00BrINexlFQbEEjLbQLNNokWPOBaMMcgCEcqNW4qNDI8IbgedZbKESGqeMhGxvU7lBVWWLe/X1Q2Xpe1maurTxJw5Wic94GK/3s/dj6/uc3eg0IscvszC8a5YBPpg== Received: from AM5EUR03FT012.eop-EUR03.prod.protection.outlook.com (10.152.16.58) by AM5EUR03HT013.eop-EUR03.prod.protection.outlook.com (10.152.16.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Thu, 21 Dec 2017 17:08:45 +0000 Received: from AM5P190MB0434.EURP190.PROD.OUTLOOK.COM (10.152.16.54) by AM5EUR03FT012.mail.protection.outlook.com (10.152.16.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via Frontend Transport; Thu, 21 Dec 2017 17:08:45 +0000 Received: from AM5P190MB0434.EURP190.PROD.OUTLOOK.COM ([fe80::9da6:f2cc:77f7:7b03]) by AM5P190MB0434.EURP190.PROD.OUTLOOK.COM ([fe80::9da6:f2cc:77f7:7b03%13]) with mapi id 15.20.0345.013; Thu, 21 Dec 2017 17:08:45 +0000 From: Khaled Omar To: Christopher Morrow , Lee Howard CC: John C Klensin , rtgwg , "irtf-discuss@irtf.org" , "idr@ietf.org" , "routing-discussion@ietf.org" Thread-Topic: When the IETF can discuss drafts seriously? Thread-Index: AQHTeQpxL62Qror8QkyB91Q7VFl5xaNMFQSAgAABn4CAACurgIAABUewgAABRACAAB4UgIABIF1ggABSkICAAByVgIAAC8aAgAACapCAAAM7gIAAAZhA Date: Thu, 21 Dec 2017 17:08:45 +0000 Message-ID: References: <51b495e6-ee1d-4224-6c7c-dec0f8248cc9@cisco.com> <60324BD8-E91D-49C7-9AE6-C6E22C836AC8@fugue.com> <1F3AC01AA49DD3BE543CCB9E@PSB> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:771BA1FF23D1052C521DDC964B123CA168381865EC6730E56700F649D715ECF7; UpperCasedChecksum:A6D96FB2A7BCDFAE96701B9C3B6C6A334C3B42B57A3B840AB2658AE10F8275F1; SizeAsReceived:8159; Count:46 x-tmn: [B4bn8E4rvY+4vFldOKN7CBP9wm5vunMV] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR03HT013; 6:WQCvkP7f+c3n5ZZPM2XQFaLDWN7iUUFfivupDZp/vgv99uF52FStPvuntySwDJn94OUu3gO3KUdPHYyzBOZfPV5/KfaPaWH52rAs9h4qpQaUhvs1M9d44RsCRiXxTy4AKRUZhkNS7zaHpwVU2anApzIjoYpmN8gucquLTMPJNXdvMBgbISfPrDRQT8uT1uQBh9jXOS5S3ZVN7ywHVI4IP+EyQEtSxb1YxO2WoRulhb2pwtyQEXU+oVCYnNzLcnw7LUu14deV3Ti/49YWSuV5TKDkjzqzjSfXtTguWrl58JKFHSnSUVHVsLIdFIHLzgYZYopy+TTGtsTFCIU1oJ+imF98sqWGvp9jW38dkRo5sy4=; 5:gn3R4uBSZJKS+lkDgjEvzR6T8XuV+aQ+8ZT7SmGWV063icpZNKuyXbdbK5lMHZPifR6wJzegMqqjswwwV/Hsf4FR6bYv/dufJiXCxdlKberSfZ8vAQAnjxH+HeC+AmQrqX4AVyt6jVGjDNgmIYYdsVCAHJN4g0TzrpJ4uUz4lXE=; 24:foGnMpGrosnW9aVrDiLwwwIPnuQxDZzAE/iAFmx0P6AKGYV4VZHaYPBPKf7XU3yZqjnBAGxRNedK9uSeBKkPyNxANAmOfzj++x8I78P7h4c=; 7:GmW5B9MDZP2kUs2eKt6P/xC6yoQgieLW+jRkhqROEmgto6DiOT+jWNaXq09VZs+tSa06gE5AZmz1d+S/v6xBC4tWemRT+wZPZCh2Ix8BksLY95CZjPyIK8N1xRQIv0tiWC0grq3sORZBkBqW7ujl92i86wb0jE3uWj7R/Nti9Pfh9WUAxNeHBz/WlFsOhm+Ron5wtAVpjdwSB0X8N6myAO3qv3RsPbbhE3cPFfrj8xc8GQZUh3k+gUyBW1otcw6/ x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR03HT013; x-ms-traffictypediagnostic: AM5EUR03HT013: x-ms-office365-filtering-correlation-id: 12f38114-2185-4332-4123-08d548957e89 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:AM5EUR03HT013; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5EUR03HT013; x-forefront-prvs: 0528942FD8 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR03HT013; H:AM5P190MB0434.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5P190MB0434D7F80A826DB2F9B89FA2AE0D0AM5P190MB0434EURP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12f38114-2185-4332-4123-08d548957e89 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2017 17:08:45.2419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR03HT013 Archived-At: Subject: Re: [Idr] When the IETF can discuss drafts seriously? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 17:08:52 -0000 --_000_AM5P190MB0434D7F80A826DB2F9B89FA2AE0D0AM5P190MB0434EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm9taW5hbCBQaHlzaWNhbCBMaW5rIENhcGFjaXR5LCBOb21DYXAoTCksIGlzIHRoZSB0aGVvcmV0 aWNhbCBtYXhpbXVtDQogICBhbW91bnQgb2YgZGF0YSB0aGF0IHRoZSBsaW5rIEwgY2FuIHN1cHBv cnQuDQoNCkl0IHN0aWxsIGRlZmluZXMgdGhlIGxpbmsgYmFuZHdpZHRoLCBJIG1lYW4gaXQgd2ls bCBub3QgYWRkIHNvbWV0aGluZyB0byB0aGUgbWV0cmljIGNhbGN1bGF0aW9ucy4NCg0KRnJvbTog aWV0ZiBbbWFpbHRvOmlldGYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdG9w aGVyIE1vcnJvdw0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDIxLCAyMDE3IDY6NTkgUE0NClRv OiBLaGFsZWQgT21hcg0KQ2M6IEpvaG4gQyBLbGVuc2luOyBpZXRmOyBydGd3Zw0KU3ViamVjdDog UmU6IFdoZW4gdGhlIElFVEYgY2FuIGRpc2N1c3MgZHJhZnRzIHNlcmlvdXNseT8NCg0KDQoNCk9u IFRodSwgRGVjIDIxLCAyMDE3IGF0IDExOjQ4IEFNLCBLaGFsZWQgT21hciA8ZW5nLmtoYWxlZC5v bWFyQGhvdG1haWwuY29tPG1haWx0bzplbmcua2hhbGVkLm9tYXJAaG90bWFpbC5jb20+PiB3cm90 ZToNCg0KPiBDYW4gd2UganVzdCBtb3ZlIHRoZSBkaXNjdXNzaW9uKHMpIHRoZXJlPyA6KQ0KDQoN Cg0KSSB3aXNoIHRvIGdvIGRpc2N1c3MgdGhlcmUsIGJ1dCB3aGVyZSB0aGVyZS4NCg0KDQpUaGUg SVJURiAtIFRoZSBJbnRlcm5ldCBSZXNlYXJjaCBUYXNrIEZvcmNlDQogIG1haWx0bzogaXJ0Zi1k aXNjdXNzQGlydGYub3JnPG1haWx0bzppcnRmLWRpc2N1c3NAaXJ0Zi5vcmc+DQoNCklEUjoNCiAg IG1haWx0bzogaWRyQGlldGYub3JnPG1haWx0bzppZHJAaWV0Zi5vcmc+DQoNCnJvdXRpbmctZGlz Y3Vzc2lvbg0KICBtYWlsdG86IHJvdXRpbmctZGlzY3Vzc2lvbkBpZXRmLm9yZzxtYWlsdG86cm91 dGluZy1kaXNjdXNzaW9uQGlldGYub3JnPg0KDQpydGd3ZyAoeW91IGFscmVhZHkgY29waWVkIHRo ZW0sIGp1c3QgbW92ZSB0aGVyZSkNCg0KDQoNCg0KDQpGcm9tOiBydGd3ZyBbbWFpbHRvOnJ0Z3dn LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Z3dnLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YgQ2hyaXN0b3BoZXIgTW9ycm93DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMjEsIDIw MTcgNjozOSBQTQ0KVG86IEpvaG4gQyBLbGVuc2luDQpDYzogcnRnd2c7IEtoYWxlZCBPbWFyOyBp ZXRmDQpTdWJqZWN0OiBSZTogV2hlbiB0aGUgSUVURiBjYW4gZGlzY3VzcyBkcmFmdHMgc2VyaW91 c2x5Pw0KDQoNCg0KVGhlIGFjdHVhbCBwcm9ibGVtIGhlcmUgaXMgdGhhdCB0aGUgZHJhZnQgZGlz Y3Vzc2lvbidzIGRvbid0IGFjdHVhbGx5IGJlbG9uZyBvbiB0aGUgSUVURkAgbGlzdCB0aG91Z2gu Li4gVGhleSBiZWxvbmcgaW4gdGhlaXIgcmVzcGVjdGl2ZSBXRyBsaXN0cywgb3IgcGVyaGFwcyBv biB0aGUgSVJURiBsaXN0Lg0KDQoNCg0KQ2FuIHdlIGp1c3QgbW92ZSB0aGUgZGlzY3Vzc2lvbihz KSB0aGVyZT8gOikNCg0KDQoNCk9uIFRodSwgRGVjIDIxLCAyMDE3IGF0IDEwOjU2IEFNLCBKb2hu IEMgS2xlbnNpbiA8am9obi1pZXRmQGpjay5jb208bWFpbHRvOmpvaG4taWV0ZkBqY2suY29tPj4g d3JvdGU6DQoNCkZvbGtzLA0KDQpNYXkgSSBzdWdnZXN0IHRoYXQgd2Ugd2luZCB0aGlzIGRpc2N1 c3Npb24gdGhyZWFkIGRvd24uDQoNCldoZXRoZXIgY29ycmVjdCBvciBub3QsIGFuYWx5c2VzIG9m IEtoYWxlZCdzIGNoYXJhY3RlciBhcmUNCnByb2JhYmx5IG5vdCBoZWxwZnVsIGFuZCByZXBldGl0 aXZlIHZlcnNpb25zIG9mIHRoZW0gYXJlIGxlc3MNCnNvLiAgVGhlIFMvTiByYXRpbyBvbiB0aGUg SUVURiBsaXN0IGlzIG5ldmVyIHdvbmRlcmZ1bCBhbmQgdGhpcw0KdGhyZWFkIHNob3VsZCBub3Qg Y29udHJpYnV0ZSB0byBtYWtpbmcgaXQgd29yc2UuDQoNCkF0IGxlYXN0IElNTywgS2hhbGVkIGhh cyBiZWVuIGdpdmVuIGEgbnVtYmVyIG9mIHF1aXRlDQpjb25zdHJ1Y3RpdmUgc3VnZ2VzdGlvbnMg KGJvdGggb24tbGlzdCBhbmQgb2ZmKSBhYm91dCBob3cgdG8NCnByb2NlZWQgaWYgaGUgd2FudHMg dG8gZG8gc28uICAgQWxtb3N0IGFsbCBvZiB0aGVtIGluY2x1ZGUNCmZvY3VzaW5nIG9uIGEgcHJv YmxlbSBzdGF0ZW1lbnQgYW5kL29yIGEgY2FyZWZ1bCBhbmQgcmVmbGVjdA0KbGl0ZXJhdHVyZSBy ZXZpZXcgYW5kIGFuYWx5c2lzLCBidXQsIGlmIGhlIHdhbnRzIHRvIG1ha2UNCnByb2dyZXNzLCBo ZSBuZWVkcyB0byB1bmRlcnN0YW5kIHRoZSBkZXRhaWxzIG9mIHRob3NlDQpzdWdnZXN0aW9ucy4N Cg0KTGV0J3MgZ2l2ZSBoaW0gdGltZSB0byBkbyB0aGF0IGFuZCBzZWUgd2hhdCwgaW4gdGhlIGZv cm0gb2YgYQ0KZHJhZnQgZm9jdXNlZCBvbiB0aG9zZSB0b3BpY3MsIGhlIGNvbWVzIHVwIHdpdGgg YW5kLCBpbiB0aGUNCnByb2Nlc3MsIHRyeSB0byByZXNlcnZlIGp1ZGdtZW50IGFib3V0IGludGVu dGlvbnMsIHF1YWxpdHkgb2YNCmxpc3RlbmluZywgZXRjLg0KDQpiZXN0LA0KICAgIGpvaG4NCg0K DQoNCg== --_000_AM5P190MB0434D7F80A826DB2F9B89FA2AE0D0AM5P190MB0434EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDM3QThGLjE2REU1RDYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjxsaW5rIHJlbD0idGhlbWVEYXRhIiBocmVmPSJ+ fnRoZW1lZGF0YX5+Ij48bGluayByZWw9ImNvbG9yU2NoZW1lTWFwcGluZyIgaHJlZj0ifn5jb2xv cnNjaGVtZW1hcHBpbmd+fiI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpXb3JkRG9jdW1l bnQ+DQo8dzpUcmFja01vdmVzLz4NCjx3OlRyYWNrRm9ybWF0dGluZy8+DQo8dzpFbnZlbG9wZVZp cy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3OlNhdmVJZlhNTEludmFsaWQ+ZmFs c2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1peGVkQ29udGVudD5mYWxzZTwvdzpJ Z25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0PmZhbHNlPC93 OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05vdFByb21vdGVRRi8+DQo8dzpMaWRU aGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQo8dzpMaWRUaGVtZUFzaWFuPlgtTk9O RTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PkFSLVNBPC93Okxp ZFRoZW1lQ29tcGxleFNjcmlwdD4NCjx3OkNvbXBhdGliaWxpdHk+DQo8dzpEb05vdEV4cGFuZFNo aWZ0UmV0dXJuLz4NCjx3OkJyZWFrV3JhcHBlZFRhYmxlcy8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQ YXJhTWFyay8+DQo8dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPC93OkNvbXBhdGliaWxpdHk+ DQo8bTptYXRoUHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtC aW4gbTp2YWw9ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNt YWxsRnJhYyBtOnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAi Lz4NCjxtOnJNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIv Pg0KPG06d3JhcEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAi Lz4NCjxtOm5hcnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3Vt ZW50Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRl bnRTdHlsZXMgRGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2Ui IERlZlNlbWlIaWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5 IiBMYXRlbnRTdHlsZUNvdW50PSIzNzEiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVh ZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJoZWFkaW5nIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUi IE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9y bWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJpbmRleCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRl eCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iaW5kZXggNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9ImluZGV4IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJOb3JtYWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Ru b3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9ImhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0idGFibGUgb2YgZmlndXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBh ZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i YW5ub3RhdGlvbiByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iZW5kbm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Im1hY3JvIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBC dWxsZXQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCBCdWxsZXQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCBOdW1iZXIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCBOdW1iZXIgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIxMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i Q2xvc2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iQm9keSBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJ bmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBD b250aW51ZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TWVzc2FnZSBIZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMTEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlNhbHV0YXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkJvZHkgVGV4dCBGaXJzdCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhl YWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iQm9keSBUZXh0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IElu ZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJCbG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVy bGluayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iU3Ryb25nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIw IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJE b2N1bWVudCBNYXAiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgVG9wIG9mIEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9y bSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iSFRNTCBBY3JvbnltIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i SFRNTCBDb2RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhU TUwgUHJlZm9ybWF0dGVkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJIVE1MIFZhcmlhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTm8gTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJPdXRsaW5lIExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBTaW1wbGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2lj IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBD bGFzc2ljIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIENvbG9yZnVsIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2x1bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29s dW1ucyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg R3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3Jp ZCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBHcmlkIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBMaXN0IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg Q29udGVtcG9yYXJ5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFN1YnRsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IlRhYmxlIFdlYiAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBUaGVtZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3Bh Y2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFt ZT0iTGlnaHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIg TmFtZT0iTWVkaXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVk aXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlk Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJM aWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlz dCAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgTmFtZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzQiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJM aWdodCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1l PSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcg QWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEi IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5h bWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu dCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1l PSJMaWdodCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJN ZWRpdW0gR3JpZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9 IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdy aWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9 Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEg QWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgi IE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29s b3JmdWwgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJJbnRlbnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjMxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJJbnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBU YWJsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBO YW1lPSJQbGFpbiBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQzIiBOYW1lPSJQbGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlk IFRhYmxlIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRh YmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9IkdyaWQgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xv cmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFt ZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFi bGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0i R3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9 IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxl IDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikdy aWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJH cmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAz IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlk IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3Jp ZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIg TmFtZT0iR3JpZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBU YWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJs ZSAxIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3 IiBOYW1lPSJMaXN0IFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy ayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0i TGlzdCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdo dCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFi bGUgNCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1 bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci IE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxl IDQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwg QWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi IE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO YW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0 IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw IiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFj Y2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO YW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg TmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt ZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjwvdzpMYXRlbnRTdHlsZXM+DQo8L3ht bD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUg NCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWls eTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6 LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQt Y2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBp dGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODcwMTQ1IDEwNzM3ODYxMTEg MSAwIDQxNSAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxl LXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6 bWlub3ItbGF0aW47fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwcmUNCgl7bXNvLXN0eWxlLW5vc2hv dzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLTsNCgltc28t c3R5bGUtdW5oaWRlOm5vO30NCnAuZ21haWwtbXNvbm9ybWFsLCBsaS5nbWFpbC1tc29ub3JtYWws IGRpdi5nbWFpbC1tc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbXNvbm9ybWFsOw0K CW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNv LXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250 LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYXNjaWktdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNv LWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3It bGF0aW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6QXJpYWw7DQoJbXNvLWJpZGktdGhlbWUtZm9u dDptaW5vci1iaWRpOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS11bmhpZGU6 bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYXNjaWktZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtdGhlbWUtZm9udDptaW5vci1sYXRpbjsNCglt c28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktdGhlbWUtZm9udDptaW5v ci1sYXRpbjsNCgltc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDsNCgltc28tYmlkaS10aGVtZS1m b250Om1pbm9yLWJpZGk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjou NWluOw0KCW1zby1mb290ZXItbWFyZ2luOi41aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9y bWFsVGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1y b3diYW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1u b3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIi Ow0KCW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdp bjowaW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9u OndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFz Y2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJbXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47fQ0KPC9zdHlsZT48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ0YWItaW50ZXJ2YWw6LjVpbiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRhYi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgz LjJwdCAyMjkuMHB0IDI3NC44cHQgMzIwLjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMu OHB0IDU0OS42cHQgNTk1LjRwdCA2NDEuMnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHls ZT0ibXNvLWFzY2lpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28t YXNjaWktdGhlbWUtZm9udDptYWpvci1iaWRpO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28taGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O21zby1oYW5zaS10aGVtZS1mb250Om1ham9yLWJpZGk7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1iaWRpLXRoZW1lLWZv bnQ6bWFqb3ItYmlkaTtjb2xvcjpibGFjayI+Tm9taW5hbA0KIFBoeXNpY2FsIExpbmsgQ2FwYWNp dHksIE5vbUNhcChMKSwgaXMgdGhlIHRoZW9yZXRpY2FsIG1heGltdW08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGFiLXN0b3BzOjQ1LjhwdCA5MS42 cHQgMTM3LjRwdCAxODMuMnB0IDIyOS4wcHQgMjc0LjhwdCAzMjAuNnB0IDM2Ni40cHQgNDEyLjJw dCA0NTguMHB0IDUwMy44cHQgNTQ5LjZwdCA1OTUuNHB0IDY0MS4ycHQgNjg3LjBwdCA3MzIuOHB0 Ij4NCjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7O21zby1hc2NpaS10aGVtZS1mb250Om1ham9yLWJpZGk7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1oYW5zaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWFqb3It YmlkaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNv LWJpZGktdGhlbWUtZm9udDptYWpvci1iaWRpO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+YW1vdW50IG9mIGRhdGEgdGhhdCB0 aGUgbGluayBMIGNhbiBzdXBwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0YWItc3RvcHM6NDUuOHB0IDkxLjZwdCAxMzcuNHB0IDE4My4ycHQg MjI5LjBwdCAyNzQuOHB0IDMyMC42cHQgMzY2LjRwdCA0MTIuMnB0IDQ1OC4wcHQgNTAzLjhwdCA1 NDkuNnB0IDU5NS40cHQgNjQxLjJwdCA2ODcuMHB0IDczMi44cHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWFzY2lpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47 bXNvLWhhbnNpLXRoZW1lLWZvbnQ6bWlub3ItbGF0aW47bXNvLWJpZGktZm9udC1mYW1pbHk6QXJp YWw7bXNvLWJpZGktdGhlbWUtZm9udDptaW5vci1iaWRpO2NvbG9yOiMxRjQ5N0QiPkl0IHN0aWxs IGRlZmluZXMgdGhlIGxpbmsgYmFuZHdpZHRoLA0KIEkgbWVhbiBpdCB3aWxsIG5vdCBhZGQgc29t ZXRoaW5nIHRvIHRoZSBtZXRyaWMgY2FsY3VsYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tYXNj aWktdGhlbWUtZm9udDptaW5vci1sYXRpbjttc28taGFuc2ktdGhlbWUtZm9udDptaW5vci1sYXRp bjttc28tYmlkaS1mb250LWZhbWlseTpBcmlhbDttc28tYmlkaS10aGVtZS1mb250Om1pbm9yLWJp ZGk7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxPcmlnaW5hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPg0KIGlldGYgW21haWx0bzppZXRmLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0b3BoZXIgTW9ycm93PGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAyMSwgMjAxNyA2OjU5IFBNPGJyPg0K PGI+VG86PC9iPiBLaGFsZWQgT21hcjxicj4NCjxiPkNjOjwvYj4gSm9obiBDIEtsZW5zaW47IGll dGY7IHJ0Z3dnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBXaGVuIHRoZSBJRVRGIGNhbiBkaXNj dXNzIGRyYWZ0cyBzZXJpb3VzbHk/PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxPcmlnaW5hbCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbCI+T24gVGh1LCBEZWMgMjEsIDIwMTcgYXQgMTE6NDggQU0sIEtoYWxlZCBPbWFy ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVuZy5raGFsZWQub21hckBob3RtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+ ZW5nLmtoYWxlZC5vbWFyQGhvdG1haWwuY29tPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbCI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWwiPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtt c28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9ImdtYWlsLW1zb25vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jmd0Ow0KPC9zcGFuPkNhbiB3ZSBqdXN0IG1vdmUgdGhlIGRpc2N1c3Npb24ocykgdGhlcmU/IDop PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW1zb25vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbXNvbm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsT3JpZ2luYWwiPkkgd2lzaCB0byBnbyBkaXNjdXNzIHRoZXJlLCBidXQgd2hlcmUg dGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW1zb25vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj5UaGUgSVJU RiAtJm5ic3A7VGhlIEludGVybmV0IFJlc2VhcmNoIFRhc2sgRm9yY2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPiZuYnNwOyBtYWlsdG86IDwvc3Bhbj48YSBocmVm PSJtYWlsdG86aXJ0Zi1kaXNjdXNzQGlydGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWwiPmlydGYtZGlzY3Vzc0BpcnRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0i bXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bCI+SURSOjxicj4NCiZuYnNwOyAmbmJzcDttYWlsdG86IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86 aWRyQGlldGYub3JnIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPmlk ckBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwi Pjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+cm91dGluZy1kaXNjdXNzaW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj4mbmJzcDsgbWFpbHRvOiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm91dGluZy1kaXNjdXNzaW9uQGlldGYub3JnIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPnJvdXRpbmctZGlzY3Vzc2lvbkBp ZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPjwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+cnRnd2cgKHlvdSBhbHJlYWR5IGNvcGllZCB0 aGVtLCBqdXN0IG1vdmUgdGhlcmUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW1zb25vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t c29ub3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iZ21haWwtbXNvbm9ybWFsIiBzdHlsZT0ibXNvLW91 dGxpbmUtbGV2ZWw6MSI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPg0KIHJ0Z3dnIFttYWlsdG86PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cnRnd2ctYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxPcmlnaW5hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ydGd3 Zy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsT3JpZ2luYWwiPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bE9yaWdpbmFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Q2hyaXN0b3BoZXIgTW9ycm93PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNl bWJlciAyMSwgMjAxNyA2OjM5IFBNPGJyPg0KPGI+VG86PC9iPiBKb2huIEMgS2xlbnNpbjxicj4N CjxiPkNjOjwvYj4gcnRnd2c7IEtoYWxlZCBPbWFyOyBpZXRmPGJyPg0KPHNwYW4gY2xhc3M9Imdt YWlsLSI+PGI+U3ViamVjdDo8L2I+IFJlOiBXaGVuIHRoZSBJRVRGIGNhbiBkaXNjdXNzIGRyYWZ0 cyBzZXJpb3VzbHk/PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iZ21haWwtbXNvbm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iZ21haWwt bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPlRoZSBh Y3R1YWwgcHJvYmxlbSBoZXJlIGlzIHRoYXQgdGhlIGRyYWZ0IGRpc2N1c3Npb24ncyBkb24ndCBh Y3R1YWxseSBiZWxvbmcgb24gdGhlIElFVEZAIGxpc3QgdGhvdWdoLi4uIFRoZXkgYmVsb25nIGlu IHRoZWlyIHJlc3BlY3RpdmUgV0cgbGlzdHMsIG9yIHBlcmhhcHMgb24gdGhlIElSVEYgbGlzdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iZ21h aWwtbXNvbm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJnbWFp bC1tc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbCI+Q2Fu IHdlIGp1c3QgbW92ZSB0aGUgZGlzY3Vzc2lvbihzKSB0aGVyZT8gOik8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJnbWFpbC1tc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 X01haWxPcmlnaW5hbCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJnbWFpbC1tc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmln aW5hbCI+T24gVGh1LCBEZWMgMjEsIDIwMTcgYXQgMTA6NTYgQU0sIEpvaG4gQyBLbGVuc2luICZs dDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpvaG4taWV0ZkBqY2suY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj5qb2huLWlldGZAamNr LmNvbTwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWwiPjwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj4mZ3Q7DQogd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iZ21haWwtbXNvbm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bCI+Rm9sa3MsPGJyPg0KPGJyPg0KTWF5IEkgc3VnZ2VzdCB0aGF0IHdlIHdpbmQgdGhpcyBkaXNj dXNzaW9uIHRocmVhZCBkb3duLjxicj4NCjxicj4NCldoZXRoZXIgY29ycmVjdCBvciBub3QsIGFu YWx5c2VzIG9mIEtoYWxlZCdzIGNoYXJhY3RlciBhcmU8YnI+DQpwcm9iYWJseSBub3QgaGVscGZ1 bCBhbmQgcmVwZXRpdGl2ZSB2ZXJzaW9ucyBvZiB0aGVtIGFyZSBsZXNzPGJyPg0Kc28uJm5ic3A7 IFRoZSBTL04gcmF0aW8gb24gdGhlIElFVEYgbGlzdCBpcyBuZXZlciB3b25kZXJmdWwgYW5kIHRo aXM8YnI+DQp0aHJlYWQgc2hvdWxkIG5vdCBjb250cmlidXRlIHRvIG1ha2luZyBpdCB3b3JzZS48 YnI+DQo8YnI+DQpBdCBsZWFzdCBJTU8sIEtoYWxlZCBoYXMgYmVlbiBnaXZlbiBhIG51bWJlciBv ZiBxdWl0ZTxicj4NCmNvbnN0cnVjdGl2ZSBzdWdnZXN0aW9ucyAoYm90aCBvbi1saXN0IGFuZCBv ZmYpIGFib3V0IGhvdyB0bzxicj4NCnByb2NlZWQgaWYgaGUgd2FudHMgdG8gZG8gc28uJm5ic3A7 ICZuYnNwO0FsbW9zdCBhbGwgb2YgdGhlbSBpbmNsdWRlPGJyPg0KZm9jdXNpbmcgb24gYSBwcm9i bGVtIHN0YXRlbWVudCBhbmQvb3IgYSBjYXJlZnVsIGFuZCByZWZsZWN0PGJyPg0KbGl0ZXJhdHVy ZSByZXZpZXcgYW5kIGFuYWx5c2lzLCBidXQsIGlmIGhlIHdhbnRzIHRvIG1ha2U8YnI+DQpwcm9n cmVzcywgaGUgbmVlZHMgdG8gdW5kZXJzdGFuZCB0aGUgZGV0YWlscyBvZiB0aG9zZTxicj4NCnN1 Z2dlc3Rpb25zLjxicj4NCjxicj4NCkxldCdzIGdpdmUgaGltIHRpbWUgdG8gZG8gdGhhdCBhbmQg c2VlIHdoYXQsIGluIHRoZSBmb3JtIG9mIGE8YnI+DQpkcmFmdCBmb2N1c2VkIG9uIHRob3NlIHRv cGljcywgaGUgY29tZXMgdXAgd2l0aCBhbmQsIGluIHRoZTxicj4NCnByb2Nlc3MsIHRyeSB0byBy ZXNlcnZlIGp1ZGdtZW50IGFib3V0IGludGVudGlvbnMsIHF1YWxpdHkgb2Y8YnI+DQpsaXN0ZW5p bmcsIGV0Yy48YnI+DQo8YnI+DQpiZXN0LDxicj4NCiZuYnNwOyAmbmJzcDsgam9objxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9ImdtYWlsLW1z b25vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsT3JpZ2luYWwiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM5P190MB0434D7F80A826DB2F9B89FA2AE0D0AM5P190MB0434EURP_-- From nobody Thu Dec 21 12:03:12 2017 Return-Path: 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 94DAB12D82F; Thu, 21 Dec 2017 12:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 le_pdAntYN5v; Thu, 21 Dec 2017 12:03:10 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-oln040092067017.outbound.protection.outlook.com [40.92.67.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC37312D7F6; Thu, 21 Dec 2017 12:03:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yFo2a3yxzyeYJi1dAfJCxpLGUgyg4vNs8Eql8hJdUrI=; b=XHWl3tw+Fplv+gfCcZty5p/+XARiPsr3WLYY5QPMs6z5cBGFifwOfmZco6yqSGpuD2bnQmq5ynq1zeQxFCT+nXVFf7En27jRSkCA1kNqHIcb69fwrwnnmye0EcaAiloDYUqDPGJqCdRn/4JAQDvhx2HeuVyUm55bE4fYvSaLYiKvat76brs20iFdfmsJ9YPQpHA6Uz88PBDIl1gwGcPVYst99/te0TwViVWmqZBeQcNzV5hqKJ27zbXE/qVOrPdGDbruF3JJwZV7PJeqCN2mVCCR2R08Z3IMSvmuwjSoPHmsnxW5WGcddsGlXAnER8cvi08C/ZHMtW1SQUXbByW/OA== Received: from AM5EUR02FT015.eop-EUR02.prod.protection.outlook.com (10.152.8.59) by AM5EUR02HT068.eop-EUR02.prod.protection.outlook.com (10.152.9.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.302.6; Thu, 21 Dec 2017 20:03:08 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com (10.152.8.52) by AM5EUR02FT015.mail.protection.outlook.com (10.152.8.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.302.6 via Frontend Transport; Thu, 21 Dec 2017 20:03:08 +0000 Received: from AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::2588:3246:d594:c004]) by AM4PR0401MB2241.eurprd04.prod.outlook.com ([fe80::2588:3246:d594:c004%17]) with mapi id 15.20.0323.018; Thu, 21 Dec 2017 20:03:08 +0000 From: Khaled Omar To: "routing-discussion@ietf.org" , "idr@ietf.org" Thread-Topic: Numbering Exchange Protocol (NEP) ID. Thread-Index: AdN6lrasnBh5TPJdSLaqi44l9SjcKQ== Date: Thu, 21 Dec 2017 20:03:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:4F34212D1DBF0163D2B1D54CDFAAE624813F5C9F06FB51B30B3409A2B61738E8; UpperCasedChecksum:A60157A3BE7369401474FB60EEEA2E233604444CDF6CD6FF1C9EA7D4D6076D46; SizeAsReceived:6894; Count:43 x-tmn: [TcSGIXQzuItSW9lBPozywb6Im7NMM6Th] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5EUR02HT068; 6:AlBtVWZv0S8Lzg2jNWKpL6JLrMlvDEK2ISR3rJDdBN634nVL2D6WS5eEnh1nBDDIXs0BVfZyK/7T1RDF4Kcb2o3N7nTgM3AlAw520lAvkMSNRaFM0uByIl6QNOB6wklnJJUiNSHG9pmdlifs3E7uYWJ2QTmvymOEd6/z5kPdm/Fxg7JmhCvG5fQ5AepIRhR67Hytl8DdJCpGgUtTyAnZFjEgsFmjLuUUe1ZTyCpu+Oeky0S7LUljTFjwAZfiWKIckb9dbl6ViLBkX+FlWdIzINcXt04pwaylunNfbwdeEpTXr4eGTdJg+9yP5T2FMOeigLBmX924J5882NR5Z4R5T72YkkxXfehJG5i0sZr0V5Q=; 5:aQk5KU9/s2F0BkFcDtbvJ5p4DmyU+Xd215NGoeyxLAn1Xt70kRff2Pie+1M1Bxd+BC2t5zUtQxjq4pjGeYib5Yr76hAG1vAiLtt1NhDiWxYEXJUg6y6hEibe/16fiIY7LSqNIr8dBa+jVDQVAINVyoW0RKLm98by5QvG0nLP67c=; 24:J+pnLjza1QRfMeAtRpoX0Q7jUdmMTMMuq63SY1SIzKbI4dY9XAvcx7pJUU1lV0jY+j98kzygzg+AFbOWj1e3X5ttHPRh7zEsfmUi2uM7UWQ=; 7:bEquG3DtfXHagqHga2IyKmdp8lgYHDDE82kbYTPJE8z9vHH32cZD0TgzpLq4TRyanlPqq3PQqrf0pgBW5dmPmzKSMA89AvSZvGxSV2EtimftsUfaUspvi45vd2x68vvPnztX8tOKsCZhSdSMiwOVxIk4uodwIJpRFKqE6Ik+1EqGg9FnZSKmvZOzYnf16/DwGhqr5y0WfBNY2Ee1LY9oig9hLFbWkjaV1WeF0JwIjF9OkEwJVH/uyFg43VWA2SFh x-incomingheadercount: 43 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR02HT068; x-ms-traffictypediagnostic: AM5EUR02HT068: x-ms-office365-filtering-correlation-id: 97f5ffaa-5ae3-42dc-3ff5-08d548addace x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:AM5EUR02HT068; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5EUR02HT068; x-forefront-prvs: 0528942FD8 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR02HT068; H:AM4PR0401MB2241.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0401MB224177D9EB9401F2E5A87BCEBD0D0AM4PR0401MB2241_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97f5ffaa-5ae3-42dc-3ff5-08d548addace X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2017 20:03:07.9660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT068 Archived-At: Subject: [Idr] Numbering Exchange Protocol (NEP) ID. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 20:03:11 -0000 --_000_AM4PR0401MB224177D9EB9401F2E5A87BCEBD0D0AM4PR0401MB2241_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here is a link to the NEP ID so we can discuss the technical details regard= ing this draft. https://tools.ietf.org/html/draft-omar-nep-02 Your comments will be highly appreciated. Regards, Khaled --_000_AM4PR0401MB224177D9EB9401F2E5A87BCEBD0D0AM4PR0401MB2241_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Here is a link to the NEP ID so we can discuss the t= echnical details regarding this draft.

 

https://tools.ietf.org/html/draft-omar-nep-02

 

Your comments will be highly appreciated.=

 

Regards,

 

Khaled

 

 

 

--_000_AM4PR0401MB224177D9EB9401F2E5A87BCEBD0D0AM4PR0401MB2241_-- From nobody Thu Dec 21 13:52:28 2017 Return-Path: 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 0167912751F; Thu, 21 Dec 2017 13:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VG8T2qZF4IFp; Thu, 21 Dec 2017 13:52:21 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 C52CE126FB3; Thu, 21 Dec 2017 13:52:20 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id w125so17788470oie.7; Thu, 21 Dec 2017 13:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=V5mJaCcct1RRPmUuPLyEtiB9xg6Lr3aqo/qmVtuLGwg=; b=FEdRGpeV+4RvU6EbYJNTS/Te6fhXkQV81hU8Fv77dFffhuTCQJF/AYdc5pFkx5emDW DW3WIQCuu5GscU71q/wPQHEG1hDRtVCetYqSHTCyICv7RVasDYkfpGIFb+ctNs0D0mQE TjAcVfpMqqHX2SXPOvYCExWtGq9R6vUPfSzJ6zpxwciZSYp8usBbNqC2bKxM3i+ghN2q hiLHJnEmFxa/kt0xhmYM+bX3Ofd1S+6IA3WXgH8LLmW6z1/tkMndf5qCgFH3Gs5gAZvY zaz0UVmDJcwJgLMU0YxVSMC6vnfrCPF5At6LE2sJdJX/iecH3mzxQCOVKL2tpRvqzAkz N27w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=V5mJaCcct1RRPmUuPLyEtiB9xg6Lr3aqo/qmVtuLGwg=; b=SOSXb0CM6WN/3fHgUwVN6Yqwuq37yMzNu03pXKVQKTzqkjx27Lbz+6xW5D6uvCFH59 OAtemYavZz9rf3GLdYqIwwWmUSyNswk9QyFqLzsGNcEFLplbFB8f8Svs/jmrnwjt6cAf NtCvJXDwGtvWmngPo0qvcGoUcCpa5ahDSVypHn4GdFdy1d/WhJVSR8zlr3bblMEOxUm/ ImWYTssCj+lEpPLD6sz7R5IC1QalLtbK5PWqQi0faiiz+h9St1aR27JpJiKXLT3TmoDl lpyEkmYJ/kxokt92f4NnzSCp92COhjx7hA1uEF9vp+bV22YgJlDArJMkVQrAXkbEgbH+ xd9g== X-Gm-Message-State: AKGB3mLZYreb83FbeIQOjse3tiR/V5CvnZtJkoVhAwxUsj5U2HeodZix Ai+LUINV4xedVoVTiT+2HMi1P3oPvEOCL8bShVA= X-Google-Smtp-Source: ACJfBos00VX7fngwmMTNjsF6y1WvwAcaK837BLwRDxgPeVCRj8UV76ie69Gv56H60TViOw8UJ7o29MWesx6SyzMe1I8= X-Received: by 10.202.245.136 with SMTP id t130mr8736597oih.356.1513893139679; Thu, 21 Dec 2017 13:52:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Dec 2017 13:52:18 -0800 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Thu, 21 Dec 2017 13:52:18 -0800 Message-ID: To: draft-ietf-idr-bgp-prefix-sid@ietf.org Cc: idr-chairs@ietf.org, Susan Hares , idr@ietf.org Content-Type: multipart/alternative; boundary="001a113d2c1ad18d7f0560e0b655" Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-bgp-prefix-sid-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 21:52:24 -0000 --001a113d2c1ad18d7f0560e0b655 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: Hi! I just finished reading this document. I have a significant number of comments (please see below). Two of them I would like to highlight up here. (1) References to draft-ietf-spring-segment-routing-msdc In the current text, draft-ietf-spring-segment-routing-msdc is not only referenced as an example of the use of the BGP Prefix-SID attribute, but in a Normative way to indicate how the attribute should be treated. While there=E2=80=99s nothing wrong with draft-ietf-spring-segment-routing-msdc (= it already passed IETF LC and is in IESG Evaluation), I=E2=80=99m sure there a= re other applications for the new attribute, right? The importance given to it in this document, which should elevate it to a Normative reference, is probably more than it deserves since it just focuses on describing "the design to deploy segment routing in [large-scale] data-centers=E2=80=9D and= it doesn=E2=80=99t contain a list of requirements nor it mandates how the new attribute should be used. Note also that draft-ietf-spring-segment-routing-msdc refers normatively to this document to explain the use case, so pointing Normatively back to it creates a loop.... Please treat draft-ietf-spring-segment-routing-msdc as what is should be: a good Informative reference =E2=80=94 I put specific co= mments above about the text below (see M1). (2) Error Handling The error handling (in Section 6) specifies that =E2=80=9Cattribute discard= =E2=80=9D (rfc7606) should be used if the attribute is malformed. I think that behavior has a direct effect on the path used to forward the traffic, which puts it then in conflict with rfc7606 because it clearly says that "Attribute discard...MUST NOT be used except in the case of an attribute th= at has no effect on route selection or installation.=E2=80=9D Please see M9 b= elow. I will wait for the Major comments to be addressed before starting the IETF LC. Thanks! Alvaro. Major: M1. References to draft-ietf-spring-segment-routing-msdc. As I mentioned above, I believe that this document gives a lot more importance to draft-ietf-spring-segment-routing-msdc than it deserves =E2=80=94 for on= e, I think that draft-ietf-spring-segment-routing-msdc should not be considered as a Normative source for this document, but as it stands right now its reference would have to in fact be Normative. M1.1 Section 1: "As described in [I-D.ietf-spring-segment-routing-msdc], the BGP Prefix-SID attribute defined in this document can be attached to prefixes from AFI/SAFI...labeled IPv4/IPv6 Unicast...unlabeled IPv6 Unicast=E2=80=9D. draft-ietf-spring-segment-routing-msdc does describe tha= t, but within the DC application =E2=80=94 IOW, just because one use case uses the= BGP Prefix SID in that way doesn=E2=80=99t mean that it determines it=E2=80=99s= use=E2=80=A6just an example. s/As described in [I-D.ietf-spring-segment-routing-msdc]/ M1.2. s/[I-D.ietf-spring-segment-routing-msdc] describes use cases where the Prefix-SID is used for the above AFI/SAFI./[I-D.ietf-spring-segment-routing-msdc] describes use cases where the Prefix-SID is used for the above AFI/SAFI in a MSDC. M1.3. Section 1: "As described in [I-D.ietf-spring-segment-routing-msdc], a BGP Prefix-SID MAY be attached to a prefix.=E2=80=9D M1.3.1. draft-ietf-spring-segment-routing-msdc doesn=E2=80=99t even use Nor= mative language M.1.3.2. ...even if it did, what is the option? Why is =E2=80=9CMAY=E2=80= =9D used? What else can the BGP Prefix-SID be attached to? Everywhere else in this document, the text talks about attachment to a prefix. M1.3.3. Section 5. (Announcing BGP-Prefix-SID Attribute) makes a similar statement: "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes (IPv4/IPv6) [RFC3107] or to IPv6 prefixes [RFC4760].=E2=80=9D Sam= e questions: is there another option? In this case, did you mean =E2=80=9C= =E2=80=A6MUST only be attached to=E2=80=A6=E2=80=9D? M1.4. Section 2.1: "As described in [I-D.ietf-spring-segment-routing-msdc] the operator assigns a globally unique =E2=80=9Cindex=E2=80=9D, L_I=E2=80= =A6=E2=80=9D. Again, that=E2=80=99s an example=E2=80=A6. s/As described in [I-D.ietf-spring-segment-routing-msdc]/ M1.4.1. [nit] BTW, is there a reason for =E2=80=9Cindex=E2=80=9D to be in = =E2=80=9C=E2=80=9D?? It isn=E2=80=99t anywhere else. M1.4.2. [minor] Also, please be consistent. In some places you use =E2=80= =9CLabel Index=E2=80=9D (as in the packet format), but also =E2=80=9Clabel index=E2= =80=9D, label_index, label-index, Label-Index, simply index or even the (redundant?) "index L_I". Some of those may be ok, but many seem to talk about the same thing while calling it by slightly different names. M1.5. Section 2.2: "As illustrated in [I-D.ietf-spring-segment-routing-msdc]...the BGP Prefix-SID consists of an IPv6 address=E2=80=A6=E2=80=9D. s/As illustrated in [I-D.ietf-spring-segmen= t-routing-msdc]/ M1.6. Section 3.3: "It is used to build segment routing policies when different SRGB's are used in the fabric ([I-D.ietf-spring-segment-routing-msdc]).=E2=80=9D I=E2=80=99m assuming that the fabric is not the only use case of having di= fferent SRGBs, right? Make the statement general and not dependent on I-D.ietf-spring-segment-routing-msdc. M1.7. Section 8: "This document defines a new BGP attribute in order to address the use case described in [I-D.ietf-spring-segment-routing-msdc].= =E2=80=9D I=E2=80=99m sure that is not the only use case=E2=80=A6reword to show it i= s an example. M1.8. Section 9: "The BGP Prefix-SID attribute addresses the requirements introduced in [I-D.ietf-spring-segment-routing-msdc]=E2=80=A6=E2=80=9D. draft-ietf-spring-segment-routing-msdc doesn=E2=80=99t actually present requirements=E2=80=A6but an application in= the DC... M2. TLV Definitions: M2.1. [minor] what is the unit used in the Length? Bytes, octets, bits M2.2. Please define a registry and a registration policy for the Flag fields. M3. What should be done if a Label-Index TLV is received if an unlabeled IPv6 prefix or if the IPv6 SID TLV is received with a labeled prefix? I assume they MUST be ignored=E2=80=A6but please include that in the text. M4. IPv6 SID TLV M4.1. Section 3.2 defines this TLV as optional ("IPv6-SID TLV MAY be present=E2=80=9D), ok. Section 4.2 then says that "If present, then the receiver assumes that the originator supports SR on the IPv6 dataplane.=E2=80=9D This seems= to indicate that the purpose of this TLV is not only to advertise an SID, but to communicate support for SR, is that correct? Later, 5.2 again says that the sender "MAY include the IPv6 SID TLV=E2=80=9D. If this TLV is not pres= ent, can the receiver assume that the originator doesn=E2=80=99t support SR? I=E2= =80=99m wondering about the optional nature of the TLV, it seems to be mandatory if the sender wants the receiver to know that it supports SR, and whenever an IPv6 SID needs to be advertised (which seems like always when using the IPv6 dataplane). What am I missing? M4.2. [nit] s/IPv6-SID/IPv6 SID M5. Section 4: "A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP neighbor residing outside the boundaries of the SR domain, SHOULD disc= ard the attribute unless it is configured=E2=80=A6=E2=80=9D. If that is the onl= y exception, then s/SHOULD/MUST M5.1. The same text is present in 4.2. If the text in 4 applies to both dataplanes, then the text in 4.2 is redundant. M6. In 4.1: "A BGP speaker MAY be locally configured with an SRGB=3D[SRGB_Start, SRGB_End]. The preferred method for deriving the SRGB = is a matter of local node configuration.=E2=80=9D Given that the "method for = deriving the SRGB is a matter of local node configuration=E2=80=9D, that =E2=80=9CMA= Y=E2=80=9D is out of place since it has no Normative value. s/MAY/may M7. Section 4.1 explains the conditions under which the BGP Prefix-SID attribute should be considered unacceptable, and it says that the receiver of =E2=80=9Can unacceptable BGP Prefix-SID attribute...MUST treat the path = as if it came without a Prefix-SID attribute.=E2=80=9D However, Section 5.1 says th= at a "speaker that advertises a path received from one of its neighbors SHOULD advertise the Prefix-SID received with the path without modification regardless of whether the Prefix-SID was acceptable=E2=80=9D. I think ther= e is a Normative contradiction here because the MUST seems to imply that the attribute is to be dropped (=E2=80=9Cas if it came without=E2=80=9D), but t= he SHOULD indicates the opposite. I can also see how the text could be interpreted as =E2=80=9Cjust ignore the attribute but forward it=E2=80=9D. Please clar= ify so there is no confusion. M7.1. I assume that the acceptable condition doesn=E2=80=99t just apply to = the MPLS data plane. It may be clearer if the text in 4.1 was moved to a common section. M7.2. Note that the same text (from 5.1) is repeated in 5.2. It may be clearer if the specification was in a common place instead. M8. Section 6: "If the BGP Prefix-SID attribute appears more than once in an BGP Update message, then, according to [RFC7606], all the occurrences of the attribute other than the first one SHALL be discarded and the BGP Updat= e message SHALL continue to be processed.=E2=80=9D Note that rfc7606 doesn= =E2=80=99t say exactly that, instead it says "all the occurrences of the attribute other than the first one SHALL be discarded and the UPDATE message will continue = to be processed=E2=80=9D. Yes, it=E2=80=99s a slight difference, but it=E2=80= =99s not the same. In this case, the Normative language is already in rfc7606, so there=E2=80=99s= no real need to repeat it here (if you do, please use =E2=80=9C=E2=80=9D). Suggest= ion: =E2=80=9C=E2=80=A6according to rfc7606, only the first occurrence will be = considered.=E2=80=9D M9. If the attribute is malformed then the index or SID in it won=E2=80=99= t be used by the receiver (attribute discard) as specified in Section 6. Section 4.1 explains how a local label is assigned if the BGP Prefix-SID attribute is unacceptable. M9.1. I=E2=80=99m assuming that the local label assignment in 4.1 includes = the case when the attribute is malformed (i.e. not just the unacceptable case). Is that true? Using a local label would result in successfully delivering the traffic to the destination, but not using the intended SR path, right? If that is true, then the malformed attribute case would have an effect on route selection/installation and could result (among other things) in the traffic taking an unwanted path due to policy, a path that is congested, etc.=E2=80=A6and that is explicitly the case where rfc7606 specifies that a= ttribute discard MUST NOT be used. It seems that any action beyond attribute discard may be too harsh given that a local label can be assigned=E2=80=A6b= ut the current specification ("MUST treat the path as if it came without a Prefix-SID attribute...MUST assign a local (also called dynamic) label=E2= =80=9D) is in conflict with rfc7606. I would be ok if the document explained the potential issues and made the local label behavior optional (pending a discussion in the WG and maybe an update to rfc7606). BTW, was this discussed in the WG (I couldn=E2=80=99t find a related discussion in the ar= chive)? M9.2. What about the IPv6 case? If the attribute is malformed, then the receiver won=E2=80=99t have an IPv6 SID to use =E2=80=94 again, there seems= to be a clear effect on route selection and installation. M10. Section 8. (Manageability Considerations). There=E2=80=99s a Normativ= e conflict on these two sentences: "By default, a BGP Prefix-SID attribute SHOULD NOT be originated and attached to a prefix. The operator MUST be capable of explicitly enabling the BGP Prefix-SID origination.=E2=80=9D Th= e =E2=80=9CMUST" indicates that the operator has to be involved, but the "SHOULD NOT" implies that there are cases where it is ok for the operator not to be involved. M11. Security Considerations M11.1. You should mention the Security Considerations of the overall SR architecture. M11.2. While I agree with the rest of this section, I think there=E2=80=99s= a new risk that is introduced by the attribute: the modification of the TLVs in transit. For example, if one of the transit BGP speakers modifies the Label Index to make it an unacceptable TLV (according to 4.1) then it would have the effect of potentially causing the traffic to take a different path. I don=E2=80=99t think there=E2=80=99s a mitigation mechanism (specia= lly because the document describes upfront the unacceptable criteria =E2=80=94 which is wha= t opens this door), but recognizing the modification risk and at least mentioning that all the routers are part of the same domain (trusted) would be a good idea. M12. The Reference to rfc4760 should be Normative. Minor: P1. Please update the Requirements Language to use the new template in rfc8174. P2. rfc3107 hs been obsoleted by rfc8277 P3. s/as_path/AS_PATH P4. s/is assumed to be done through/is done through P5. "As defined in [I-D.ietf-spring-segment-routing-mpls], the index L_I is an offset in the SRGB.=E2=80=9D The reference should be I-D.ietf-spring-segment-routing (that is where the index and the SRGB are explained). P6. Please be consistent when referring to the new attribute: s/Prefix-SID attribute/BGP Prefix-SID attribute Nits: N1. s/It i assumed/It is assumed --001a113d2c1ad18d7f0560e0b655 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Dear authors:

Hi!=C2=A0 I just finished readin= g this document.

I=C2=A0have a significant num= ber of comments (please see below).=C2=A0 Two of them I would like to highl= ight up here.

(1)=C2=A0References to draft-iet= f-spring-segment-routing-msdc

In the current t= ext, draft-ietf-spring-segment-routing-msdc is not only referenced as an ex= ample of the use of the BGP Prefix-SID attribute, but in a Normative way to= indicate how the attribute should be treated.=C2=A0 While there=E2=80=99s = nothing wrong with draft-ietf-spring-segment-routing-msdc (it already passe= d IETF LC and is in IESG Evaluation), I=E2=80=99m sure there are other appl= ications for the new attribute, right?=C2=A0 The importance given to it in = this document, which should elevate it to a Normative reference, is probabl= y more than it deserves since it just focuses on describing "the desig= n to deploy segment routing in [large-scale] data-centers=E2=80=9D and it d= oesn=E2=80=99t contain a list of requirements nor it mandates how the new a= ttribute should be used.=C2=A0 Note also that=C2=A0draft-ietf-spring-segmen= t-routing-msdc refers normatively to this document to explain the use case,= so pointing Normatively back to it creates a loop....=C2=A0 Please treat draft-ietf-spring-segment-routi= ng-msdc as what is should be: a good Informative reference =E2=80=94 I put = specific comments above about the text below (see M1).


(2) Error Handling

=
= The error handling (in Section 6) specifies that=C2=A0=E2=80=9Cattribute di= scard=E2=80=9D (rfc7606)=C2=A0should be used if the attribute is malformed.= =C2=A0 I think that behavior has a direct effect on the path used to forwar= d the traffic, which puts it then in conflict with rfc7606 because it clear= ly says that "Attribute discard...MUST NOT be used except in the case of an attribute=C2=A0that has no effect on route selection or installatio= n.=E2=80=9D =C2=A0Please see M9 below.


I will wait for the Major comments to be addres= sed before starting the IETF LC.

Th= anks!

Alvaro.

Major:

= M1. References to=C2=A0draft-ietf-spring-s= egment-routing-msdc.=C2=A0 As I mentioned above, I believe that this document gives a lot more importance to=C2=A0draft-ietf-spring-segment-routing-msdc than it deserves =E2=80=94 for one, I think that draft-ietf-spring-segment-routing-msdc should not be considered as a Normative source for this document, but as it stands right now its reference would have to in fact be Normative. =C2=A0

= M1.1 Section 1: "As described = in [I-D.ietf-spring-segment-routing-msdc], the BGP Prefix-SID attribute defined in this document can be attached to prefixes from AFI/SAFI...labeled IPv4/IPv6 Unicast...unlabeled IPv6 Unicast=E2=80=9D. =C2=A0draft-ietf-spring-segment-routing-msdc does describe that, but within the DC application =E2=80=94 IOW, just because one use case uses the BGP Prefix SID in that way doesn=E2=80=99t mean that it determines it= =E2=80=99s use=E2=80=A6just an example. =C2=A0s/As described in [I-D.ietf-spring-segme= nt-routing-msdc]/=C2=A0

M1.2. s/[I-D.ietf-spri= ng-segment-routing-msdc] describes use cases where the=C2=A0Prefix-SID is used for the above AFI/SAFI./[I= -D.ietf-spring-segment-routing-msdc] describes use cases where the=C2=A0Prefix-SID is used for the above = AFI/SAFI in a MSDC.
=
= M1.3. Section 1: "As described in [I-D.ietf-spring-segment-routing-msd= c], a BGP=C2=A0Prefix-SID MAY = be attached to a prefix.=E2=80=9D =C2=A0

M1.3.= 1. draft-ietf-spring-segment-routing-msdc doesn=E2=80=99t even use Normativ= e language

M.1.3.2. ...even if it did, what i= s the option?=C2=A0 Why is =E2=80=9CMAY=E2=80=9D used?=C2=A0 What else can = the BGP Prefix-SID be attached to? =C2=A0Everywhere else in this document, the text talks about attachmen= t to a prefix. =C2=A0

M1.3.3. Section=C2=A05. = (Announcing BGP-Prefix-SID Attribute) makes a similar statement: "The = BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes=C2=A0(IPv4/IPv6) [RFC3107] or to IPv6 pr= efixes [RFC4760].=E2=80=9D =C2=A0Same questions: is there another option?= =C2=A0 In this case, did you mean =E2=80=9C=E2=80=A6MUST only be attached t= o=E2=80=A6=E2=80=9D?

M1.4. Section 2.1: "= As described in [I-D.ietf-spring-segment-routing-msdc] the=C2=A0operator assigns a globally unique =E2=80= =9Cindex=E2=80=9D, L_I=E2=80=A6=E2=80=9D.=C2=A0 Again, that=E2=80=99s an ex= ample=E2=80=A6. s/As described in [I-D.ietf-spring-segment-routing-msdc]/

M1.4.1. [nit] BTW, is there a reason for =E2=80= =9Cindex=E2=80=9D to be in =E2=80=9C=E2=80=9D??=C2=A0 It isn=E2=80=99t anyw= here else.

M1.4.2. [minor] Also, please be co= nsistent.=C2=A0 In some places you use =E2=80=9CLabel Index=E2=80=9D (as in= the packet format), but also =E2=80=9Clabel index=E2=80=9D, label_index, l= abel-index, Label-Index, simply index or even the (redundant?) "index = L_I".=C2=A0 Some of those may be ok, but many seem to talk about the s= ame thing while calling it by slightly different names.

M1.5. Section 2.2: "As illustrated in [I-D.ietf-spring-segme= nt-routing-msdc]...the BGP Prefix-SID consists of an IPv6=C2=A0address=E2=80=A6=E2=80=9D. s/As illustrate= d in [I-D.ietf-spring-segment-routing-msdc]/

<= div id=3D"bloop_customfont" style=3D"margin:0px">M= 1.6. Section 3.3: "It is used to build segment routing policies=C2=A0<= /font>when different SRGB's are u= sed in the fabric=C2=A0([I-D.i= etf-spring-segment-routing-msdc]).=E2=80=9D =C2=A0I=E2=80=99m assuming that= the fabric is not the only use case of having different SRGBs, right?=C2= =A0 Make the statement general and not dependent on=C2=A0I-D.ietf-spring-se= gment-routing-msdc.

M1.7. Section 8: "Thi= s document defines a new BGP attribute in order to address the use=C2=A0case described in [I-D.ietf-sprin= g-segment-routing-msdc].=E2=80=9D =C2=A0I=E2=80=99m sure that is not the on= ly use case=E2=80=A6reword to show it is an example.

M1.8. Section 9: "The BGP Prefix-SID attribute addresses the re= quirements introduced in=C2=A0= [I-D.ietf-spring-segment-routing-msdc]=E2=80=A6=E2=80=9D.=C2=A0draft-ietf-s= pring-segment-routing-msdc doesn=E2=80=99t actually present requirements=E2= =80=A6but an application in the DC...


M2. TLV Definitions:=C2=A0

M2.1. [= minor] what is the unit used in the Length?=C2=A0 Bytes, octets, bits

<= font face=3D"Helvetica">M2.2. Please define a registry and a registration p= olicy for the Flag fields.


=
M3. What should be done if a Label-Index TLV is received if an= unlabeled IPv6 prefix or if the IPv6 SID TLV is received with a labeled pr= efix?=C2=A0 I assume they MUST be ignored=E2=80=A6but please include that i= n the text.
<= font face=3D"Helvetica">

M4.=C2=A0<= span style=3D"font-family:Helvetica">IPv6 SID TLV

M4.1. Section 3.2 defines this TLV as optional ("IPv6-SID TLV MAY = be present=E2=80=9D), ok.=C2=A0 Section 4.2 then says that "If present= , then the receiver=C2=A0assum= es that the originator supports SR on the IPv6 dataplane.=E2=80=9D =C2=A0Th= is seems to indicate that the purpose of this TLV is not only to advertise = an SID, but to communicate support for SR, is that correct?=C2=A0 Later, 5.= 2 again says that the sender "MAY include the IPv6 SID TLV=E2=80=9D.= =C2=A0 If this TLV is not present, can the receiver assume that the origina= tor doesn=E2=80=99t support SR?=C2=A0 I=E2=80=99m wondering about the optio= nal nature of the TLV, it seems to be mandatory if the sender wants the rec= eiver to know that it supports SR, and whenever an IPv6 SID needs to be adv= ertised (which seems like always when using the IPv6 dataplane).=C2=A0 What= am I missing?

M4.2. [nit] s/IPv6-SID/IPv6 SID=


M5. Section 4= : "A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP=C2= =A0neighbor residing outside t= he boundaries of the SR domain, SHOULD=C2=A0discard the attribute unless it is configured=E2=80=A6=E2=80= =9D. If that is the only exception, then s/SHOULD/MUST

M5.1. The same text is present in 4.2.=C2=A0 If the text in 4 app= lies to both dataplanes, then the text in 4.2 is redundant.

M6. In 4.1: "A BGP speaker MAY be loca= lly configured with an SRGB=3D[SRGB_Start,=C2=A0SRGB_End].=C2=A0 The preferred method for deriving the SR= GB is a matter of=C2=A0local n= ode configuration.=E2=80=9D =C2=A0Given that the "method for deriving = the SRGB is a matter of=C2=A0l= ocal node configuration=E2=80=9D, that =E2=80=9CMAY=E2=80=9D is out of plac= e since it has no Normative value. =C2=A0s/MAY/may

<= /div>

M7.= =C2=A0Section 4.1 explains the conditions under wh= ich the BGP Prefix-SID attribute should be considered unacceptable, and it = says that the receiver of=C2=A0=E2=80=9Can=C2=A0unacceptable BGP Prefix-SID attribute...MUST treat the pa= th as if it came=C2=A0without = a Prefix-SID attribute.=E2=80=9D =C2=A0However, Section 5.1 says that a &qu= ot;speaker that advertises a path received from one of its=C2=A0neighbors SHOULD advertise the Prefix-SID= received with the path=C2=A0w= ithout modification regardless of whether the Prefix-SID was=C2=A0acceptable=E2=80=9D.=C2=A0 I think ther= e is a Normative contradiction here because the MUST seems to imply that th= e attribute is to be dropped (=E2=80=9Cas if it came without=E2=80=9D), but= the SHOULD indicates the opposite.=C2=A0 I can also see how the text could= be interpreted as =E2=80=9Cjust ignore the attribute but forward it=E2=80= =9D.=C2=A0 Please clarify so there is no confusion.

=
M7.1. I assume that the acceptable condition doesn=E2=80=99t just app= ly to the MPLS data plane.=C2=A0 It may be clearer if the text in 4.1 was m= oved to a common section.

M7.2. Note that the = same text (from 5.1) is repeated in 5.2.=C2=A0 It may be clearer if the spe= cification was in a common place instead.


=
M8. Section 6: "If the BGP Prefix-SID attribute appears= more than once in an BGP=C2=A0Update message, then, according to [RFC7606], all the occurrences of the a= ttribute other than the first one SHALL be discarded and the BGP=C2=A0Update message SHALL continue to be= processed.=E2=80=9D =C2=A0Note that rfc7606 doesn=E2=80=99t say exactly th= at, instead it says "all the occurrences of the attribute other than t= he=C2=A0first one SHALL be dis= carded and the UPDATE message will continue=C2=A0to be processed=E2=80=9D.=C2=A0 Yes, it=E2=80=99s a slig= ht difference, but it=E2=80=99s not the same.=C2=A0 In this case, the Norma= tive language is already in rfc7606, so there=E2=80=99s no real need to rep= eat it here (if you do, please use =E2=80=9C=E2=80=9D).=C2=A0 Suggestion: = =C2=A0=E2=80=9C=E2=80=A6according to rfc7606, only the first occurrence wil= l be considered.=E2=80=9D


M9.= =C2=A0If the attribute is mal= formed then the index or SID in it won=E2=80=99t be used by the receiver (a= ttribute discard) as specified in Section 6.=C2=A0 Section 4.1 explains how= a local label is assigned if the BGP Prefix-SID attribute is unacceptable.=

M9.1. I=E2=80=99m assuming that the local l= abel assignment in 4.1 includes the case when the attribute is malformed (i= .e. not just the unacceptable case).=C2=A0 Is that true? =C2=A0 Using a loc= al label would result in successfully delivering the traffic to the destina= tion, but not using the intended SR path, right?=C2=A0 If that is true, the= n the malformed attribute case would have an effect on route selection/inst= allation and could result (among other things) in the traffic taking an unw= anted path due to policy, a path that is congested, etc.=E2=80=A6and that i= s explicitly the case where rfc7606 specifies that attribute discard MUST N= OT be used.=C2=A0 It seems that any action beyond attribute discard may be = too harsh given that a local label can be assigned=E2=80=A6but the current = specification ("MUST treat the path as if it came=C2=A0without a Prefix-SID attribute...MUST assign = a local (also called dynamic)=C2=A0label=E2=80=9D) is in conflict with rfc7606. =C2=A0 I would be ok if t= he document explained the potential issues and made the local label behavio= r optional (pending a discussion in the WG and maybe an update to rfc7606).= =C2=A0 BTW, was this discussed in the WG (I couldn=E2=80=99t find a related= discussion in the archive)?

M9.2. What about = the IPv6 case?=C2=A0 If the attribute is malformed, then the receiver won= =E2=80=99t have an IPv6 SID to use=C2=A0=E2=80=94=C2=A0again, there seems t= o be a clear effect on route selection and installation.

<= span style=3D"font-family:Helvetica">
M10. Sec= tion=C2=A08. (Manageability Considerations). =C2=A0There=E2=80=99s a Normative conflict on these two sent= ences: "By default, a BGP Prefix-SID attribute SHOULD NOT be=C2=A0originated and attached to a prefi= x.=C2=A0 The operator MUST be capable=C2=A0of explicitly enabling the BGP Prefix-SID origination.=E2=80= =9D =C2=A0The =E2=80=9CMUST" indicates that the operator has to be inv= olved, but the "SHOULD NOT" implies that there are cases where it= is ok for the operator not to be involved.


M11. Security Co= nsiderations

M11.1. You should mention the Security Considerations of the overall SR ar= chitecture.

M11.2. While=C2= =A0I agree with the rest of this section, I think there=E2=80=99s a new ris= k that is introduced by the attribute: the=C2=A0modification of the TLVs in= transit.=C2=A0 For example, if one of the transit BGP speakers modifies th= e Label Index to make it an unacceptable TLV (according to 4.1) then it wou= ld have the effect of potentially causing the traffic to take a different p= ath.=C2=A0 I don=E2=80=99t think there=E2=80=99s a mitigation mechanism (sp= ecially=C2=A0because the document describes upfront the unacceptable criter= ia=C2=A0=E2=80=94 which is what opens this door), but recognizing the modif= ication risk and at least mentioning that all the routers are part of the s= ame domain (trusted) would be a good idea.

M12. The Reference to rfc4760 should be Normative.



Minor:

P1. Plea= se update the Requirements Language to use the new template in rfc8174.

P2. rfc3107 hs been obsolete= d by rfc8277

P3.= s/as_path/AS_PATH

P4. s/is assumed to be done through/is done through

P5. "As defined in [I-D.ietf-spring= -segment-routing-mpls], the index=C2=A0L_I is an offset in the SRGB.=E2=80=9D =C2=A0The reference should = be=C2=A0I-D.ietf-spring-segment-routing (that is where the index and the SR= GB are explained). =C2=A0

P6. Please be consistent when referring to the new attribute: s/Pre= fix-SID attribute/BGP Prefix-SID attribute

=

Nits:

= N1. s/It i=C2=A0assumed/It is= =C2=A0assumed

--001a113d2c1ad18d7f0560e0b655-- From nobody Fri Dec 22 07:50:29 2017 Return-Path: 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 E70CC12711A; Fri, 22 Dec 2017 07:50:27 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 mp0mEDWGz00r; Fri, 22 Dec 2017 07:50:26 -0800 (PST) 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 116A6124239; Fri, 22 Dec 2017 07:50:26 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBMFnBtm006224; Fri, 22 Dec 2017 07:50:23 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=PPS1017; bh=B6aIVzswFd03tWTe8lVvP01DOIJmBGs4I8FRkcLNvJc=; b=g2mRp+/iul47YYWgDb+PfsCZHAGzJNnTW8EiGVCqTjfwOfZk+XPNxuX/ke339wWr91Mp YcfMwlUKCM0z1T0KdxUcIJk2531Mo9Z/jwrEtU80CgwgCzbesOQ1HLeE0Gt8CUvQgv4b weyWT9f3Bgp7QWCthUvWRAcbG1tTOdMFpkshPeJkVP3jK27Gdfa+ObAVsQv1tlX242K2 SzQRb5QIeibsMQV8GJ3uzuvTsZqgQsTR/8eUMg/9ozuPtyRa5VxFyzLvBQolYEn/fg7z IVsF/BadtbaH+TECTvcT7p7zoZQ5yqvDIlLUW56NmfF3GVDgHSJfE7z7De4Qj6VBhqMJ sw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0023.outbound.protection.outlook.com [207.46.163.23]) by mx0a-00273201.pphosted.com with ESMTP id 2f14js81t3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 22 Dec 2017 07:50:23 -0800 Received: from [172.29.37.99] (66.129.241.12) by CY1PR05MB2297.namprd05.prod.outlook.com (10.166.192.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.3; Fri, 22 Dec 2017 15:50:20 +0000 To: Alvaro Retana , draft-ietf-idr-bgp-prefix-sid@ietf.org Cc: idr-chairs@ietf.org, Susan Hares , idr@ietf.org References: From: Eric C Rosen Message-ID: Date: Fri, 22 Dec 2017 10:50:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0A65418840028E25E36F0C0E" Content-Language: en-US X-Originating-IP: [66.129.241.12] X-ClientProxiedBy: MWHPR03CA0002.namprd03.prod.outlook.com (10.175.133.140) To CY1PR05MB2297.namprd05.prod.outlook.com (10.166.192.143) X-MS-Office365-Filtering-Correlation-Id: 6126b692-5172-4250-7085-08d54953b545 X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(5600026)(4604075)(48565401081)(2017052603307)(7153060); SRVR:CY1PR05MB2297; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2297; 3:W8p+7jYRhLPMsvrDiJZze4HGH57gVziR+5z/jTJtLWTDIToqwU+gcg0BBu8lDXEIbwzrr32MXkAtBxoWlGmGmIifQwVGm7Az7UVUjSqr/eS8+CFLdNJDQsF8c4DPZw684Qz3tpW2i75XynFem9Ruff0qvX3H4sn3UJavNABf5FDabw8LRx3Ory50h6hgUejFHVy9fhFzMP8ORqY+x+9RgmK9jf8I0OqkNd4x1AjpT95XYBFt1qVnSi479yKuopiF; 25:2zlC+jBb0z/99E3kOpydeW+ybJUeWfTZM6HA4gJHsOYGD3ckMH7sf7ZRgvFx5mmgT2AMJZixmhoO5olZZTynfI6hMm2PkyRKXsTS2XVmsAfSktIytUmt1yyKhyyrY/zcwxjz975WNTtbzVRkZ9pVMOm6N7djmP9/IuezUNFLL+Lsuk/ze7+5Dvwj0cRiS3b4frvGpzhJ/lZP8c7ezTIMATnz2vSt5BXnxPmznkenlsGOg8YBPcNn+VrEjuhbkmTfUMdGV438fTqJzxPoFYABKgTD+4Xkj8HoIA25oDstdzpdYH7PNbkF123uu7WmGigHhrWHllQXl9MKAT7ZrxImbg==; 31:L5fHgN69NsFQP5xrkCUfIUe3LqPEDnbnZsPLlMJ5R7tOrgeF0ZgS69+qn0qEPV+H3hDibxiEbAiIfE2OngRL87xyvE/6HmYznEe+pbpvMngJhNKIe1BogQGvaTW5mg3bnXIWuLfhzSG8MAP9DJplIOtA1IN3AV+RgVJlueiOBxXbI1Xy0NzNPYlyqNFciSMOVkBYlhxqAaiS0Lm3g0dSZS4EEiZakbUPnx8QfLWuF7c= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CY1PR05MB2297: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2297; 20:5k9PdNLtn+Jq7ji6PJ6bmCdIGdkoqfb+ozwx2lnkbA/m/xg6upYu8exIG8evJIG8N4qv1aT2NrTbO7/+8uLAibcdqfZU66/LabHzWEf74GmDkVOGDVd0jIcDKIRIsvkmzU6mgkjUVBGpi8Wq4uecbfxEq2c2gSNp7bS53in67i5CLIl33+bg+uwPmiqGXwbm9TtJYg41xpgczZ0lHdoyo4tsrdrMI87LQuMLHD5iIfajs9XcB/47Ow5n77Gx3C4DW2Y1Eguf9S01awfUAKiGO5gozbdcP4xBZ/Odj2j6J3vOhvO/dhIdl41//wLF3JLqDepopdj4Lss8pr0vZu2bygYwggDHOW3S3QVWyKv5DWVNuk7c/HN5z0eOcBszCbOGGysFcXVvqR46E35tRd5say0/RFPM8zE/1+n6RrJVTFGqbYK4xRVT8INOeYwXA1Scfr+JLeR4DO5QOFYG/ODGtagdDMlCblrIpk9COBYJczF7jzBGIccK1vxjLZtkV4r9rparR2TF1VQ2/VVVUhvqsTjQgc6OK3WNWTCWWunT+V/YKDE3Dx+gy/YEqz3wKjSlIXgmvvykYZKfNJeuxUMD8jKHgYg1pcbNFlUsfpJywdY=; 4:QhF/q7pkroP49tC23b59Zi+I4v4I/CAi9kNOa8D3T9xkr+0LelcVRnZv9T0a4BMyvPSL5bcmXqy6RnAxlna8hJ8xgk3/wq1qrU2UmN/yivFKVHvFPOqEhAxPlHFxLA1fKAqQjiuJoWq4PJb2L3jm60e0nKUhHT7tZj0SzNJ09Oj4U1ZiYJEyAXgfdkqczqQa/9YsTbXa1gQqUiB5zS2JvAfBx6Rorr+ENN9sjfFriB4VtDfsR/Th4+77QIqqV6AWfUfCOIYBUQIYoAKFQnmtFw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231023)(944501045)(93006095)(93001095)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY1PR05MB2297; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY1PR05MB2297; X-Forefront-PRVS: 05299D545B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39860400002)(396003)(346002)(39380400002)(376002)(366004)(51444003)(24454002)(189003)(199004)(58126008)(316002)(25786009)(3846002)(4326008)(77096006)(3260700006)(37036004)(6116002)(16586007)(64126003)(2950100002)(6666003)(5660300001)(16526018)(16576012)(33964004)(2906002)(97736004)(31696002)(86362001)(68736007)(84326002)(6246003)(39060400002)(53936002)(90366009)(6486002)(66066001)(386003)(54896002)(65956001)(65826007)(81156014)(53546011)(83506002)(81166006)(7736002)(65806001)(36756003)(106356001)(8936002)(229853002)(230783001)(59450400001)(31686004)(52116002)(76176011)(105586002)(478600001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB2297; H:[172.29.37.99]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB2297; 23:2KL66dfmTqp+AUzdAn75otZQrf6DShCdKf8INB56h?= =?us-ascii?Q?ZaSkA7coEtRhg96ixH09ntEi6RLa5sjByO93457GAKCQTMiwsRU+SvEuquDE?= =?us-ascii?Q?uFqFoK0xFLOA9rZzFs1/eejeVopiVohVo9APvgkQxSczn0ilDJMx5Ae9bJdi?= =?us-ascii?Q?eeyRyVu32BJyN+CBgA3B5IccP7m2fxgLkuW24QU9L5TiivpgcUJ8MPc+W1+V?= =?us-ascii?Q?qyzI4ivk1HEAfGSP/k92mf2caj1bJoGNF5GxHGZ8rShmXiLi8ZLQ4IzLtWK4?= =?us-ascii?Q?4/yRQDRvuBnGeRT3aZpQYGZpLE7SSY46ycTWNeBIVE5ahiWvgTAsxiGEJcQ5?= =?us-ascii?Q?PtNIMlpFyXnlJZT3zsoLc5jAajKxCRHeo28hcRL0bduwxvERjcRVpzWqc67O?= =?us-ascii?Q?Kzf9OyO9wwxIzaftG6zXmQakt3SmtG15tFlsnkC5dp3vqs7czwXUufu9L0Wo?= =?us-ascii?Q?xrjMBKZqezoIMPU7wm1qn6ehFQUU2uTi0pngtGyUlFb4zJMjtf0I7FhBXxiB?= =?us-ascii?Q?Z+FMaePmPUH50cMTpsE3yjH+i95uyF4b+RwerD7IPYitYh0buCegyNzP5ZHg?= =?us-ascii?Q?RUqzF1lxisw5butzWI8ehRvoT0L82CShpM6YeRvJDLBRiI/WXl14SbfPU2/d?= =?us-ascii?Q?vXtPKPvVk5EzUp8UugyWi7rggA5VFii5e2WZt9n7zoyASvyn+X09DBSB/VK/?= =?us-ascii?Q?4e8tXw9/0oXVNoT9NUG4pPryD1w7anP+MOiXuwGgoEqEsK8tBtHRZPHVEpQa?= =?us-ascii?Q?sEOedOcfgzpyyyrUudvwrmDP3G/cULsfA09rh9J1UMfWJ5PDUW++zB6GDjoJ?= =?us-ascii?Q?bPLPsZrshQz0/yJkYSGuoeV1qoVXBiodZS8StwSWPVNcu8bQKlj5cMTPultl?= =?us-ascii?Q?BzwQfw025MQu9m8Wf6pIr1xL2C3Geov8ZQILrTgiIU95IissWDHcC5nKBkm3?= =?us-ascii?Q?Lpz7XxHMwqgxifnv61oQoMFuBzhlOAVq4lgUGH130ojot3YVJYLg3Ixlh1xl?= =?us-ascii?Q?1zP/G6ml27WSi6WztIcMBOy8/B3qhFIDcZhmKpvBWghrXa+dS9PkKgZIir+u?= =?us-ascii?Q?7vZE9e/E3pyZip6Y/l+dw1o+HeEGaqNaHq/56oIVfKdsLJeaogc6HLuAtzbQ?= =?us-ascii?Q?gHRO3nrgysV6ezvJyzxYBieX47ifeycRDHNackIFZY3qwZOSfW9w+h5l7mIu?= =?us-ascii?Q?04Y+RN92FKcLPUiwJDK3HS1M5at9yjJzvl52hBHATUpdsWdVDH5BIlkz/Sd0?= =?us-ascii?Q?q3JY8kDE2QnTiPu1/GY5jdicFfWISKF8ApL8YpiCnhZpKJ8hMQbxUMqfh747?= =?us-ascii?Q?w9e6YaXmE1JfOvMdcmCIQo7Rf/ReHH8IFVJzZy+vtuS1Bh7Vtjiix0pivSqy?= =?us-ascii?Q?YEIa92RJ7F3XlrvkYgqxFKfEDQzgUXpyyvpgpzOxTknGAX/SBcmPTjWsk63W?= =?us-ascii?Q?wIoFeLoMg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB2297; 6:/P+L9hiXe/3ngmQ1NiULC3koaAuD19FVcGMelOo2i9Pu40/3t7VoXzRnvzO1R4PfBBq/5vN1jeyP0xunIjDs0pTfUqmZZSdCgKdV62M8VQnh36vrQQbdQ1wnytSSgZPGHbgaDit2ybjToZxwvLMLrHDSOirQrYr2UUO2pI04kwPGW2j6jCWeQTJYhtozou8qG7ksU74Eg5GgeEicHrKfej+RaNAAM5qdzGiiayNGl/McOcTDPGObOC+KqOdqrpBr+8UdxypI38kKlSuAblV0j/5Rbvm51/HZm6NJXsjIQxesC6sj2TbWY3GXymoVt4aVX41DAtetj+lr64oO8VNU08DqgaHGt2FMPXApav/ebGA=; 5:dvoFcpOdrZFHIvcZ1yxW3OmR6xAbUCLWTJy2FW+N/iCEuraIkFlG+eyWxrLvkQaMNLxLOPpLF84pVG8fahH+t1hSG+jO9gD68HpdePVCqSz6KvC9ssaN0vDemw3P80mc3azJ4GTqbsnLAM5ARC+gvIs0nlBgdupqRQ66ShbUAXs=; 24:cCbBXBa9nXHV/9C2h2roWUcsIIdRQ1R4N8l4qJDW+CyC5R10ZLsT5pEnXGEh1FZdIR6z7zOPQDmaCunA71l231yKxVGH6ILIn4RdQ7bFGz4=; 7:aA6/08XPWOEtQVsw9SsB4cIClDju3bw61HwG5DZNfGfO4y1RyTMgidDugWTj1hYsalxbeHV2FGOKcO8XAvUxvKTztGS600NXhU17xppH8dqDEnZ8hYQzY/mksPWl/8Iw7Hw9pkgorT9HC3SzKgU5s+JYETN/+Y0uTmjpROeZxbXxSe/pmPawwTN/k3OjQ8uvE7Eem3V90Ns3L5a2hC9P+tH2MxdMIh2gwRYdsCbInURpDVNXRgyPuVyQDB7jiRFe SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Dec 2017 15:50:20.2164 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6126b692-5172-4250-7085-08d54953b545 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB2297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-22_06:, , 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-1711220000 definitions=main-1712220223 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-prefix-sid-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 15:50:28 -0000 This is a multi-part message in MIME format. --------------0A65418840028E25E36F0C0E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/21/2017 4:52 PM, Alvaro Retana wrote: I don't think the following point is correct. > (2) Error Handling > > The error handling (in Section 6) specifies that “attribute discard” > (rfc7606) should be used if the attribute is malformed.  I think that > behavior has a direct effect on the path used to forward the traffic, > which puts it then in conflict with rfc7606 because it clearly says > that "Attribute discard...MUST NOT be used except in the case of an > attribute that has no effect on route selection or installation.” >  Please see M9 below. > > M9. If the attribute is malformed then the index or SID in it won’t be > used by the receiver (attribute discard) as specified in Section 6.  > Section 4.1 explains how a local label is assigned if the BGP > Prefix-SID attribute is unacceptable. > > M9.1. I’m assuming that the local label assignment in 4.1 includes the > case when the attribute is malformed (i.e. not just the unacceptable > case).  Is that true?   Using a local label would result in > successfully delivering the traffic to the destination, but not using > the intended SR path, right?  If that is true, then the malformed > attribute case would have an effect on route selection/installation > and could result (among other things) in the traffic taking an > unwanted path due to policy, a path that is congested, etc.…and that > is explicitly the case where rfc7606 specifies that attribute discard > MUST NOT be used.  It seems that any action beyond attribute discard > may be too harsh given that a local label can be assigned…but the > current specification ("MUST treat the path as if it came without a > Prefix-SID attribute...MUST assign a local (also called dynamic) > label”) is in conflict with rfc7606.   I would be ok if the document > explained the potential issues and made the local label behavior > optional (pending a discussion in the WG and maybe an update to > rfc7606).  BTW, was this discussed in the WG (I couldn’t find a > related discussion in the archive)? > The presence of absence of the prefix-SID attribute is not taken into account in any way by the BGP bestpath selection process, so it has no effect on "route selection or installation".  Thus I don't see any conflict between this draft and RFC 7606. If I understand correctly, the intention of the prefix-SID attribute on a BGP-LU route is the following.  When a router receives a BGP-LU route for prefix X with label L1, it propagates that that route with a locally assigned label L2.  The prefix-SID attribute tells the router what the value of L2 should be.  But if the router uses a different value of L2, that doesn't change the path followed by the data.  Thus "treat as withdraw" does not seem like the proper response to a malformed prefix-SID attribute, whereas "attribute-discard" seems appropriate. I'm less sure what the impact of a malformed prefix-SID attribute is when the dataplane is not MPLS. --------------0A65418840028E25E36F0C0E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/21/2017 4:52 PM, Alvaro Retana wrote:

I don't think the following point is correct.

(2) Error Handling

The error handling (in Section 6) specifies that “attribute discard” (rfc7606) should be used if the attribute is malformed.  I think that behavior has a direct effect on the path used to forward the traffic, which puts it then in conflict with rfc7606 because it clearly says that "Attribute discard...MUST NOT be used except in the case of an attribute that has no effect on route selection or installation.”  Please see M9 below.


M9.  If the attribute is malformed then the index or SID in it won’t be used by the receiver (attribute discard) as specified in Section 6.  Section 4.1 explains how a local label is assigned if the BGP Prefix-SID attribute is unacceptable.

M9.1. I’m assuming that the local label assignment in 4.1 includes the case when the attribute is malformed (i.e. not just the unacceptable case).  Is that true?   Using a local label would result in successfully delivering the traffic to the destination, but not using the intended SR path, right?  If that is true, then the malformed attribute case would have an effect on route selection/installation and could result (among other things) in the traffic taking an unwanted path due to policy, a path that is congested, etc.…and that is explicitly the case where rfc7606 specifies that attribute discard MUST NOT be used.  It seems that any action beyond attribute discard may be too harsh given that a local label can be assigned…but the current specification ("MUST treat the path as if it came without a Prefix-SID attribute...MUST assign a local (also called dynamic) label”) is in conflict with rfc7606.   I would be ok if the document explained the potential issues and made the local label behavior optional (pending a discussion in the WG and maybe an update to rfc7606).  BTW, was this discussed in the WG (I couldn’t find a related discussion in the archive)?


The presence of absence of the prefix-SID attribute is not taken into account in any way by the BGP bestpath selection process, so it has no effect on "route selection or installation".  Thus I don't see any conflict between this draft and RFC 7606.

If I understand correctly, the intention of the prefix-SID attribute on a BGP-LU route is the following.  When a router receives a BGP-LU route for prefix X with label L1, it propagates that that route with a locally assigned label L2.  The prefix-SID attribute tells the router what the value of L2 should be.  But if the router uses a different value of L2, that doesn't change the path followed by the data.  Thus "treat as withdraw" does not seem like the proper response to a malformed prefix-SID attribute, whereas "attribute-discard" seems appropriate.

I'm less sure what the impact of a malformed prefix-SID attribute is when the dataplane is not MPLS.





--------------0A65418840028E25E36F0C0E-- From nobody Sat Dec 23 00:40:56 2017 Return-Path: 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 89732127201; Sat, 23 Dec 2017 00:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ynwJZyxydsc0; Sat, 23 Dec 2017 00:40:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 3F3B71201F8; Sat, 23 Dec 2017 00:40:42 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 010B85A08DDE3; Sat, 23 Dec 2017 08:40:39 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 23 Dec 2017 08:40:39 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Sat, 23 Dec 2017 16:40:32 +0800 From: Xuxiaohu To: "idr@ietf.org" CC: "ospf@ietf.org" , "isis-wg@ietf.org" , "spring@ietf.org" Thread-Topic: A comment regarding the relationship between RLD and ERLD Thread-Index: AQHTe8mxXY34rgOrrk2zXgV1aEAl0Q== Date: Sat, 23 Dec 2017 08:40:32 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] A comment regarding the relationship between RLD and ERLD X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 08:40:46 -0000 SGkgYWxsLA0KDQpJIGp1c3QgcmVhZCB0aGUgZHJhZnQgKGRyYWZ0LWlldGYtaWRyLWJncC1scy1z ZWdtZW50LXJvdXRpbmctcmxkKSBkdWUgdG8gdGhlIGN1cmlvc2l0eSBvZiB0aGUgRVJMRCB0ZXJt aW5vbG9neS4gSSBoYXZlIHRob3VnaHQgdGhhdCB0aGlzIGRyYWZ0IGlzIGp1c3QgYWJvdXQgYSBz dHJhaWdodGZvcndhcmQgQkdQLUxTIGV4dGVuc2lvbiBmb3IgdGhlIFJMRCBjb25jZXB0IGFzIGRl ZmluZWQgaW4gZHJhZnQtaWV0Zi1vc3BmLW1wbHMtZWxjIGFuZCBkcmFmdC1pZXRmLWlzaXMtbXBs cy1lbGMgYWNjb3JkaW5nIHRvIHRoZSBkcmFmdCBuYW1lLiBIb3dldmVyIGl0IGlzbid0IGluIGZh Y3QuIE1heWJlIHRoZSBkcmFmdCBuYW1lIHNob3VsZCBoYXZlIGJlZW4gKi1lcmxkIHJhdGhlciB0 aGFuICotcmxkLg0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cyBvbiB0aGlzIGRyYWZ0 IChkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLXJsZCk6DQoNCjEpIEVSTEQg bWVhbnMgRW50cm9weSBjYXBhYmxlIFJlYWRhYmxlIExhYmVsIERlcHRoIGFzIGRlZmluZWQgaW4g dGhpcyBkcmFmdC4gSG93ZXZlciwgaXQgc2FpZCAiLi4uQSBuZXR3b3JrIG5vZGUgc2lnbmFsbGlu ZyBhbiBFUkxEIE1VU1Qgc3VwcG9ydCB0aGUgYWJpbGl0eSB0byByZWFkIHRoZSBzaWduYWxsZWQg bnVtYmVyIG9mIGxhYmVscyBiZWZvcmUgYW55IGFjdGlvbiBpcyBkb25lIHVwb24gdGhlIHBhY2tl dC4uLiIgSSdtIHdvbmRlcmluZyB3aGF0IGFjdGlvbnMgb3RoZXIgdGhhbiB0aGUgRUwtYmFzZWQg TEIgYWN0aW9uIHRoZSAiYW55IGFjdGlvbiIgY291bGQgYmUgc2luY2UgdGhlIEVSTEQgaGFzIGJl ZW4gdGlnaHRseSBjb3VwbGVkIHdpdGggdGhlIEVMLWJhc2VkIExCIG1lY2hhbmlzbS4gSW4gY29u dHJhc3QsIHRoZSBSTEQgYXMgZGVmaW5lZCBpbiB0aGUgdHdvIElHUCBkcmFmdHMgaXMgbm90IHRp Z2h0bHkgY291cGxlIHdpdGggdGhlIEVMLWJhc2VkIExCIGFjdGlvbi4gSW4gb3RoZXIgd29yZHMs IHRoZSBSTEQgY2FwYWJpbGl0eSBjb3VsZCBiZSBhcHBsaWNhYmxlIHRvIG90aGVyIHVzZSBjYXNl cyBiZXNpZGVzIHRoZSBFTC1iYXNlZCBMQi4NCg0KMikgSXQgc2FpZCAiLi4uSW4gZXhpc3Rpbmcg dGVjaG5vbG9neSBib3RoIElTSVMgWzRdIGFuZCBPU1BGIFszXSBoYXZlIHByb3Bvc2VkIGV4dGVu c2lvbnMgdG8gc2lnbmFsIHRoZSBSTEQgKFJlYWRhYmxlIExhYmVsIERlcHRoKSBhbmQgRUxDIChF bnRyb3B5IExhYmVsIENhcGFiaWxpdHkpIG9mIGEgbm9kZSBvciBsaW5rLiAiIEhvd2V2ZXIsIHRo ZXJlIGlzIG5vIGV4dGVuc2lvbnMgdG8gc2lnbmFsIHRoZSBSTEQgYW5kIEVMQyBvZiBhIGxpbmss IGlmIEkgcmVtZW1iZXJlZCBjb3JyZWN0bHkgYXMgYSBjby1hdXRob3Igb2YgdGhlIGFib3ZlIHR3 byBJR1AgZHJhZnRzOikgSW4gZmFjdCwgd2hlbiB0aGUgdHdvIElHUCBkcmFmdHMgd2VyZSBpbml0 aWFsbHkgcHJvcG9zZWQsIHNvbWUgZ3V5cyBkb2VzIGFyZ3VlIHdoeSBub3QgYWR2ZXJ0aXNlIEVM QyBhbmQgUkxEIG9mIHRoZSBwZXItbGluayBncmFudWxhcml0eSBhcyB3ZWxsLiBBZnRlciBzb21l IGRpc2N1c3Npb24gaW4gSUVURiwgYSByb3VnaCBjb25zZW5zdXMgaGFkIGJlZW4gcmVhY2hlZCB0 aGF0IHRoZSBhZHZlcnRpc2VtZW50IG9mIEVMQyBhbmQgUkxEIGF0IGEgcGVyIG5vZGUgZ3JhbnVs YXJpdHkgd2FzIGdvb2QgZW5vdWdoIGF0IHRoYXQgdGltZS4gVGhhdCdzIHRoZSByZWFzb24gd2h5 IHRoZSB0d28gSUdQIGRyYWZ0cyBoYWQgbm90IGJlZW4gZXh0ZW5kZWQgdG8gYWR2ZXJ0aXNlIEVM QyBhbmQgUkxEIGF0IGEgcGVyIGxpbmsgZ3JhbnVsYXJpdHkgdGhlcmVmb3JlLiBNYXliZSB3ZSBz aG91bGQgcmVvcGVuIHN1Y2ggZGlzY3Vzc2lvbiBub3c/DQoNCjMpIEl0IHNhaWQgIi4uLmlmIGEg bmV0d29yayBTRE4gY29udHJvbGxlciBpcyBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsgdGhyb3Vn aCBhIEJHUC1MUyBzZXNzaW9uIGFuZCBub3QgdGhyb3VnaCBJU0lTIG9yIE9TUEYgdGVjaG5vbG9n eSwgdGhlbiBib3RoIFJMRCBhbmQgRUxDIG5lZWRzIHRvIGJlIHNpZ25hbGVkIGluIEJHUC1MUyBh Y2NvcmRpbmdseS4gIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBleHRlbnNpb24gQkdQLUxT IHJlcXVpcmVzIHRvIHRyYW5zcG9ydCB0aGUgY29tYmluYXRpb24gb2YgUkxEIGFuZCBFTEMgaW50 byBhY2NvcmRpbmcgRVJMRCBhdHRyaWJ1dGVzIGZvciBub2RlcyBhbmQgbGlua3MuLi4iIEkgaGF2 ZSBub3QgeWV0IGZvdW5kIGFueSBleHBsYW5hdGlvbiBhYm91dCB0aGUgbW90aXZhdGlvbiBmb3Ig YWR2ZXJ0aXNpbmcgdGhlIGNvbWJpbmF0aW9uIG9mIFJMRCBhbmQgRUxDIGludG8gYWNjb3JkaW5n IEVSTEQgYXR0cmlidXRlcyByYXRoZXIgdGhhbiBhZHZlcnRpc2luZyB0aGVzZSB0d28gYXR0cmli dXRlcyBzZXBhcmF0ZWx5LiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gZ2l2ZSBhbnkgZXhwbGFuYXRp b24gYWJvdXQgc3VjaCBtb3RpdmF0aW9uIGluIHRoZSBQcm9ibGVtIFN0YXRlbWVudCBzZWN0aW9u Pw0KDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3 orz+yMs6IEtldGFuIFRhbGF1bGlrYXIgKGtldGFudCkgW21haWx0bzprZXRhbnRAY2lzY28uY29t XQ0KPiC3osvNyrG85DogMjAxN8TqMTLUwjIxyNUgMTI6MTYNCj4gytW8/sjLOiBYdXhpYW9odTsg TGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IENocmlzdGlhbiBIb3BwczsgaXNpcy13Z0BpZXRmLm9y Zw0KPiCzrcvNOiBpc2lzLWFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91 dGluZy1tc2RAaWV0Zi5vcmcNCj4g1vfM4jogUkU6IFtJc2lzLXdnXSBXRyBMYXN0IENhbGwgZm9y IGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkLTA3DQo+IA0KPiBIaSBYdSwNCj4g DQo+IEkgYW0gYXJndWluZyB0aGUgZXhhY3Qgb3Bwb3NpdGUgb2Ygd2hhdCB5b3UgYXJlIHNheWlu Zy4NCj4gDQo+IExldCB1cyBsZWF2ZSBFTEMvRVJMRCBhc2lkZSBzaW5jZSBpdCBpcyB2ZXJ5IGxp bWl0ZWQgdG8gZW50cm9weSBsYWJlbCB1c2UtY2FzZSBhbmQNCj4gdGhlIHByb3Bvc2VkIElHUC9C R1AtTFMgZW5jb2RpbmcgaXMgdmVyeSBzcGVjaWZpYyB0byB0aGF0LiBJIGFtIG5vdCBzdXJlIGlm IHRoaXMgaXMNCj4gdGhlIHRpbWUgYW55bW9yZSB0byByZXZpc2l0IHRoYXQuDQo+IA0KPiBUaGUg TVNEIHByb3Bvc2FsIGNhbWUgbGF0ZXIgYW5kIEkgc3VwcG9ydCBpcyBzaW5jZSBJJ3ZlIGZvdW5k IGl0cyB1c2UgdG8gYmUNCj4gbXVjaCBtb3JlIHdpZGVzcHJlYWQgYW5kIHRoZSBwcm9wb3NlZCBJ R1AvQkdQLUxTIHByb3RvY29sIGVuY29kaW5nIHRvIGJlDQo+IHZlcnkgZWZmaWNpZW50IGFzIGFu IGltcGxlbWVudGVyIG9mIHRoZXNlIHByb3RvY29scy4gSGVuY2UgdGhlIHJlcXVlc3QgdG8gbm90 DQo+IHJlc3RyaWN0IGl0IHRvICJ3cml0YWJsZSIgb3IgImltcG9zaXRpb24iIGNhc2VzIHNvbGVs eS4gSXQgaXMgYWxzbyBub3QganVzdCBhYm91dA0KPiAicmVhZGFiaWxpdHkiIC0gd2hpY2ggYnkg aXRzZWxmIGlzIHByZXR0eSBtZWFuaW5nbGVzcy4gRXZlbiBFUkxEIGlzIGFib3V0DQo+ICJyZWFk aW5nIiBhbmQgdGhlbiAiZG9pbmcgKnNvbWV0aGluZyBzcGVjaWZpYyogYWJvdXQgaXQiIGFzIGRp c2N1c3NlZCBpbg0KPiBpZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy4NCj4gDQo+IFRo ZXJlIGlzIG5vIHNlY29uZCB0aG91Z2h0cyBhYm91dCB0aGUgSUdQIEVMQyBkcmFmdHMgYW5kIHRo ZXkgYXJlIHZlcnkgdXNlZnVsDQo+IGFuZCBuZWNlc3NhcnkuIEp1c3QgdG8gYmUgY2xlYXIgdGhl cmUgaXMgKm5vIGZ1bmN0aW9uYWwgb3Igb3BlcmF0aW9uYWwgY2hhbmdlKg0KPiB0aGF0IEkgYW0g YXJndWluZyBmb3IgaGVyZS4gVGhlIGRpc2N1c3Npb24gaXMgcHVyZWx5IG9uIHRoZSB3YXkgdG8g aGFuZGxlIHRoZXNlDQo+IGVuY29kaW5ncyBhbmQgd2hldGhlciB3ZSBjYW4gdXNlIHRoZSBNU0Qg bWVjaGFuaXNtIGluIGEgZ2VuZXJhbGl6ZWQNCj4gbWFubmVyLg0KPiANCj4gVGhhbmtzLA0KPiBL ZXRhbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUg W21haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tXQ0KPiBTZW50OiAyMSBEZWNlbWJlciAyMDE3IDA4 OjEwDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsg S2V0YW4gVGFsYXVsaWthciAoa2V0YW50KQ0KPiA8a2V0YW50QGNpc2NvLmNvbT47IENocmlzdGlh biBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBpc2lzLXdnQGlldGYub3JnDQo+IENjOiBpc2lz LWFkc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2RAaWV0Zi5v cmcNCj4gU3ViamVjdDogtPC4tDogW0lzaXMtd2ddIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2QtMDcNCj4gDQo+IEhpIExlcywNCj4gDQo+IElmIEkg dW5kZXJzdGFuZCBpdCBjb3JyZWN0bHksIHRoZSBNU0QgY29uY2VwdCB3YXMgb3JpZ2luYXRlZCBm cm9tDQo+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wY2Utc2VnbWVu dC1yb3V0aW5nLTExI3BhZ2UtNykgYXMNCj4gZGVzY3JpYmVkIGJlbG93Og0KPiANCj4gIlRoZSAi TWF4aW11bSBTSUQgRGVwdGgiICgxDQo+ICAgIG9jdGV0KSBmaWVsZCAoTVNEKSBzcGVjaWZpZXMg dGhlIG1heGltdW0gbnVtYmVyIG9mIFNJRHMgKE1QTFMgbGFiZWwNCj4gICAgc3RhY2sgZGVwdGgg aW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVudCkgdGhhdCBhIFBDQyBpcyBjYXBhYmxlIG9m DQo+ICAgIGltcG9zaW5nIG9uIGEgcGFja2V0LiINCj4gDQo+IEJlZm9yZSBjb25zaWRlcmluZyBl eHBhbmRpbmcgdGhlIHNlbWFudGljcyBvZiB0aGUgTVNEIGNvbmNlcHQgYXMgZGVmaW5lZCBpbg0K PiB0aGUgYWJvdmUgUENFLVNSIGRyYWZ0LCBob3cgYWJvdXQgZmlyc3QgY29uc2lkZXJpbmcgcmVu YW1pbmcgdGhlIGNhcGFiaWxpdHkgb2YNCj4gaW1wb3NpbmcgdGhlIG1heGltdW0gbnVtYmVyIG9m IGxhYmVscyBzbyBhcyB0byBlbGltaW5hdGUgcG9zc2libGUgY29uZnVzaW9ucywNCj4gZS5nLiwg V3JpdGFibGUgTGFiZWwtc3RhY2sgRGVwdGggKFdMRCkgYXMgb3Bwb3NlZCB0byB0aGUgUmVhZGFi bGUgTGFiZWwtc3RhY2sNCj4gRGVwdGggKFJMRCkgYXMgZGVmaW5lZCBpbiAoaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3NwZi1tcGxzLWVsYykNCj4gYW5kIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLW1wbHMtZWxjKSA/DQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiANCj4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiC3 orz+yMs6IElzaXMtd2cgW21haWx0bzppc2lzLXdnLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gTGVz IEdpbnNiZXJnDQo+ID4gKGdpbnNiZXJnKQ0KPiA+ILeiy83KsbzkOiAyMDE3xOoxMtTCMjHI1SA0 OjAyDQo+ID4gytW8/sjLOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpOyBDaHJpc3RpYW4gSG9w cHM7IGlzaXMtd2dAaWV0Zi5vcmcNCj4gPiCzrcvNOiBpc2lzLWFkc0BpZXRmLm9yZzsgZHJhZnQt aWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1tc2RAaWV0Zi5vcmcNCj4gPiDW98ziOiBSZTogW0lz aXMtd2ddIFdHIExhc3QgQ2FsbCBmb3INCj4gPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0 aW5nLW1zZC0wNw0KPiA+DQo+ID4gS2V0YW4gLQ0KPiA+DQo+ID4gVGhhbnggZm9yIHRoZSBjb21t ZW50cy4NCj4gPiBJIHRoaW5rIHdlIGRvIHdhbnQgdG8gYWxsb3cgTVNEIHN1cHBvcnQgZm9yIHZh bHVlcyBvdGhlciB0aGFuDQo+ID4gaW1wb3NpdGlvbiB2YWx1ZXMuIFdlIHdpbGwgcmV2aXNlIHRo ZSB0ZXh0IHNvIHdlIGFyZSBub3QgcmVzdHJpY3RlZCB0byBvbmx5DQo+IGltcG9zaXRpb24gY2Fz ZXMuDQo+ID4NCj4gPiAgIExlcw0KPiA+DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gPiBGcm9tOiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpDQo+ID4gPiBTZW50 OiBXZWRuZXNkYXksIERlY2VtYmVyIDIwLCAyMDE3IDE6NTEgQU0NCj4gPiA+IFRvOiBDaHJpc3Rp YW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPjsgaXNpcy13Z0BpZXRmLm9yZw0KPiA+ID4gQ2M6 IGlzaXMtYWRzQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZEBp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUkU6IFtJc2lzLXdnXSBXRyBMYXN0IENhbGwgZm9yDQo+ ID4gPiBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLW1zZC0wNw0KPiA+ID4NCj4gPiA+ IEhlbGxvLA0KPiA+ID4NCj4gPiA+IEkgc3VwcG9ydCB0aGlzIGRvY3VtZW50IGFuZCB3b3VsZCBs aWtlIHRvIGFzayB0aGUgYXV0aG9ycyBhbmQgV0cgdG8NCj4gPiA+IGNvbnNpZGVyIGlmIHdlIGNh biBleHBhbmQgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQgdG8gbm90IGp1c3QNCj4gPiA+ICJpbXBv c2l0aW9uIiBvZiB0aGUgU0lEIHN0YWNrIGJ1dCBhbHNvIG90aGVyIHNpbWlsYXIgbGltaXRzIHJl bGF0ZWQNCj4gPiA+IHRvIG90aGVyDQo+ID4gYWN0aW9ucyAoZS5nLg0KPiA+ID4gcmVhZGluZywg cHJvY2Vzc2luZywgZXRjLikuIFdpdGggU2VnbWVudCBSb3V0aW5nLCB3ZSBhcmUgY29taW5nDQo+ ID4gPiBhY3Jvc3MgdmFyaW91cyBhY3Rpb25zIHRoYXQgbm9kZXMgbmVlZCB0byBkbyB3aXRoIHRo ZSBTSUQgc3RhY2sgZm9yDQo+ID4gPiBkaWZmZXJlbnQgcHVycG9zZXMgYW5kIElNSE8gaXQgd291 bGQgYmUgdXNlZnVsIHRvIGV4dGVuZCB0aGUgTVNEDQo+ID4gPiBhYmlsaXR5IHRvIGNvdmVyIHRo b3NlIGFzIHRoZXkgYXJpc2UuDQo+ID4gPg0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gS2V0YW4NCj4g PiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogSXNpcy13 ZyBbbWFpbHRvOmlzaXMtd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4gPiBD aHJpc3RpYW4gSG9wcHMNCj4gPiA+IFNlbnQ6IDIwIERlY2VtYmVyIDIwMTcgMTQ6MDMNCj4gPiA+ IFRvOiBpc2lzLXdnQGlldGYub3JnDQo+ID4gPiBDYzogaXNpcy1hZHNAaWV0Zi5vcmc7IGRyYWZ0 LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctbXNkQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBb SXNpcy13Z10gV0cgTGFzdCBDYWxsIGZvcg0KPiA+ID4gZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQt cm91dGluZy1tc2QtMDcNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGF1dGhvcnMgaGF2ZSBhc2tl ZCBmb3IgYW5kIHdlIGFyZSBzdGFydGluZyBhIFdHIExhc3QgQ2FsbCBvbg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWlzaXMt c2VnbWVudC1yb3V0aW5nLW1zZA0KPiA+ID4gLw0KPiA+ID4NCj4gPiA+IHdoaWNoIHdpbGwgbGFz dCBhbiBleHRlbmRlZCA0IHdlZWtzIHRvIGFsbG93IGZvciB5ZWFyLWVuZCBQVE8gcGF0dGVybnMu DQo+ID4gPg0KPiA+ID4gQW4gSVBSIHN0YXRlbWVudCBleGlzdHM6DQo+ID4gPg0KPiA+ID4NCj4g PiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/c3VibWl0PWRyYWZ0 JmlkPWRyYWZ0LWlldGYtDQo+ID4gPiBpcw0KPiA+ID4gaXMtDQo+ID4gPiBzZWdtZW50LXJvdXRp bmctbXNkDQo+ID4gPg0KPiA+ID4gQXV0aG9ycyBwbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3QgaW5k aWNhdGluZyB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YNCj4gPiA+IGFueQ0KPiA+ID4gKm5ldyog SVBSLg0KPiA+ID4NCj4gPiA+IFRoYW5rcywNCj4gPiA+IENocmlzLg0KPiA+ID4NCj4gPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBJc2lz LXdnIG1haWxpbmcgbGlzdA0KPiA+ID4gSXNpcy13Z0BpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pc2lzLXdnDQo+ID4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IElzaXMtd2cgbWFpbGlu ZyBsaXN0DQo+ID4gSXNpcy13Z0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXNpcy13Zw0K From nobody Sat Dec 23 01:25:21 2017 Return-Path: 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 392721275C5; Sat, 23 Dec 2017 01:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 OoHdelSJzkFH; Sat, 23 Dec 2017 01:25:10 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 DDDA81201F8; Sat, 23 Dec 2017 01:25:09 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P1E00C00PT4KY00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 09:25:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1514021109; bh=ixTaz46T1Bjyr4VS5XOL3MvGSPqo2WNulL4czEzLrKw=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=gE0q0tGrK8/Z3rL6dXeiZHviI9Xd/0LetMnd+KKwrLHYOXg3M7njTgEdI+f2iDnwW iq3uttXnh42ld6E+xXplNlohw96QRyuMi81J25jT3w4xn7jB5sGgggJxRIsonAWELF wTnhf5M1AZehxdr6nUUavz8Ojhy5gIQ+xM/H3yYH65mPG9gwR8wmtQdUl5daLze/W/ 0uLHnVdd1rr93BHEJCHqLcb6JONTWCNpsJXE8TnkXPCXS+bYY1EYcwjx176oNcEHa5 9tUr9z/KyMCBaLWRjfxm5GgtwzM3kJiRE3QZOF2mhkEQaPna4hRXZEQyEcwSSXTkIi Dmz/FyHnqKP0g== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P1E00MVSQ5TQH00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 09:25:08 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712230129 From: Gunter Van De Velde Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 23 Dec 2017 10:25:05 +0100 In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> Cc: "idr@ietf.org" , "ospf@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Idr] A comment regarding the relationship between RLD and ERLD X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 09:25:13 -0000 --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Xiaohu, Thanks for digging through the draft. See inline: GV> > On 23 Dec 2017, at 09:40, Xuxiaohu wrote: >=20 > Hi all, >=20 > I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) due = to the curiosity of the ERLD terminology. I have thought that this draft = is just about a straightforward BGP-LS extension for the RLD concept as = defined in draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc = according to the draft name. However it isn't in fact. Maybe the draft = name should have been *-erld rather than *-rld. >=20 > I have the following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld): >=20 > 1) ERLD means Entropy capable Readable Label Depth as defined in this = draft. However, it said "...A network node signalling an ERLD MUST = support the ability to read the signalled number of labels before any = action is done upon the packet..." I'm wondering what actions other than = the EL-based LB action the "any action" could be since the ERLD has been = tightly coupled with the EL-based LB mechanism. In contrast, the RLD as = defined in the two IGP drafts is not tightly couple with the EL-based LB = action. In other words, the RLD capability could be applicable to other = use cases besides the EL-based LB. >=20 GV> This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in:=20 https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . = Consensus from IETF100 IDR meeting was that ERLD is the way forward for = BGP-LS based signalling, and that maybe this should also be the case for = both ISIS and OSPF drafts (however, that is different discussion). I = agree with IDR consensus and it seems the most pragmatic path forward. > 2) It said "...In existing technology both ISIS [4] and OSPF [3] have = proposed extensions to signal the RLD (Readable Label Depth) and ELC = (Entropy Label Capability) of a node or link. " However, there is no = extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now? >=20 GV> I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW. If for = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 we = just need node based ERLD, then I that is just fine. My personal opinion = is that we need node ERLD for node for sure in BGP-LS, and that link = ERLD is a nice to have. It seems relative easy and pragmatic to add both = Link and node ERLD in current version of the BGP-LS ERLD document. > 3) It said "...if a network SDN controller is connected to the network = through a BGP-LS session and not through ISIS or OSPF technology, then = both RLD and ELC needs to be signaled in BGP-LS accordingly. This = document describes the extension BGP-LS requires to transport the = combination of RLD and ELC into according ERLD attributes for nodes and = links..." I have not yet found any explanation about the motivation for = advertising the combination of RLD and ELC into according ERLD = attributes rather than advertising these two attributes separately. = Would it be better to give any explanation about such motivation in the = Problem Statement section? >=20 >=20 GV> Yes, indeed, again that was reason again that the work was presented = during IETF100 as I had some doubts myself. During IETF100 IDR meeting, = I learned and was confirmed that ERLD is now in the SPRING entropy label = draft and that hence ERLD is to be signalled for the most prominent = use-case driving readable label depth signalling https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . I = see no reason to open that discussion again, and current BGP-LS ERLD = draft is inline the most dominant use-case scenario (Entropy based = load-balancing). I could change the existing text to refer to = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = = and only mention ERLD (and no longer mention ELC/RLD at all) if IDR WG = find that better? Brgds, G/ > Best regards, > Xiaohu >=20 >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) = [mailto:ketant@cisco.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 12:16 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); = Christian Hopps; isis-wg@ietf.org >> =E6=8A=84=E9=80=81: isis-ads@ietf.org; = draft-ietf-isis-segment-routing-msd@ietf.org >> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>=20 >> Hi Xu, >>=20 >> I am arguing the exact opposite of what you are saying. >>=20 >> Let us leave ELC/ERLD aside since it is very limited to entropy label = use-case and >> the proposed IGP/BGP-LS encoding is very specific to that. I am not = sure if this is >> the time anymore to revisit that. >>=20 >> The MSD proposal came later and I support is since I've found its use = to be >> much more widespread and the proposed IGP/BGP-LS protocol encoding to = be >> very efficient as an implementer of these protocols. Hence the = request to not >> restrict it to "writable" or "imposition" cases solely. It is also = not just about >> "readability" - which by itself is pretty meaningless. Even ERLD is = about >> "reading" and then "doing *something specific* about it" as discussed = in >> ietf-spring-segment-routing-mpls. >>=20 >> There is no second thoughts about the IGP ELC drafts and they are = very useful >> and necessary. Just to be clear there is *no functional or = operational change* >> that I am arguing for here. The discussion is purely on the way to = handle these >> encodings and whether we can use the MSD mechanism in a generalized >> manner. >>=20 >> Thanks, >> Ketan >>=20 >> -----Original Message----- >> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >> Sent: 21 December 2017 08:10 >> To: Les Ginsberg (ginsberg) ; Ketan Talaulikar = (ketant) >> ; Christian Hopps ; = isis-wg@ietf.org >> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>=20 >> Hi Les, >>=20 >> If I understand it correctly, the MSD concept was originated from >> = (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) = as >> described below: >>=20 >> "The "Maximum SID Depth" (1 >> octet) field (MSD) specifies the maximum number of SIDs (MPLS label >> stack depth in the context of this document) that a PCC is capable = of >> imposing on a packet." >>=20 >> Before considering expanding the semantics of the MSD concept as = defined in >> the above PCE-SR draft, how about first considering renaming the = capability of >> imposing the maximum number of labels so as to eliminate possible = confusions, >> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable = Label-stack >> Depth (RLD) as defined in = (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc) >> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ? >>=20 >> Best regards, >> Xiaohu >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg = [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les Ginsberg >>> (ginsberg) >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 4:02 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian = Hopps; isis-wg@ietf.org >>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; = draft-ietf-isis-segment-routing-msd@ietf.org >>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>> draft-ietf-isis-segment-routing-msd-07 >>>=20 >>> Ketan - >>>=20 >>> Thanx for the comments. >>> I think we do want to allow MSD support for values other than >>> imposition values. We will revise the text so we are not restricted = to only >> imposition cases. >>>=20 >>> Les >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ketan Talaulikar (ketant) >>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>> To: Christian Hopps ; isis-wg@ietf.org >>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>> Subject: RE: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hello, >>>>=20 >>>> I support this document and would like to ask the authors and WG to >>>> consider if we can expand the scope of this draft to not just >>>> "imposition" of the SID stack but also other similar limits related >>>> to other >>> actions (e.g. >>>> reading, processing, etc.). With Segment Routing, we are coming >>>> across various actions that nodes need to do with the SID stack for >>>> different purposes and IMHO it would be useful to extend the MSD >>>> ability to cover those as they arise. >>>>=20 >>>> Thanks, >>>> Ketan >>>>=20 >>>> -----Original Message----- >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of >>>> Christian Hopps >>>> Sent: 20 December 2017 14:03 >>>> To: isis-wg@ietf.org >>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>> Subject: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>>=20 >>>> The authors have asked for and we are starting a WG Last Call on >>>>=20 >>>>=20 >>>> = https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd >>>> / >>>>=20 >>>> which will last an extended 4 weeks to allow for year-end PTO = patterns. >>>>=20 >>>> An IPR statement exists: >>>>=20 >>>>=20 >>>> = https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf- >>>> is >>>> is- >>>> segment-routing-msd >>>>=20 >>>> Authors please reply to the list indicating whether you are aware = of >>>> any >>>> *new* IPR. >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>=20 >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Xiaohu,

Thanks for = digging through the draft.

See inline: GV>

On 23 = Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi = all,

I just read the draft = (draft-ietf-idr-bgp-ls-segment-routing-rld) due to the curiosity of the = ERLD terminology. I have thought that this draft is just about a = straightforward BGP-LS extension for the RLD concept as defined in = draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the = draft name. However it isn't in fact. Maybe the draft name should have = been *-erld rather than *-rld.

I have the = following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld):

1) ERLD means Entropy capable Readable Label Depth as defined = in this draft. However, it said "...A network node signalling an ERLD = MUST support the ability to read the signalled number of labels before = any action is done upon the packet..." I'm wondering what actions other = than the EL-based LB action the "any action" could be since the ERLD has = been tightly coupled with the EL-based LB mechanism. In contrast, the = RLD as defined in the two IGP drafts is not tightly couple with the = EL-based LB action. In other words, the RLD capability could be = applicable to other use cases besides the EL-based LB.


GV> = This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. Consensus from IETF100 IDR meeting was that ERLD is the way = forward for BGP-LS based signalling, and that maybe this should also be = the case for both ISIS and OSPF drafts (however, that is different = discussion).  I agree with IDR consensus and it seems the most = pragmatic path forward.


2) It said "...In existing technology both ISIS [4] and OSPF = [3] have proposed extensions to signal the RLD (Readable Label Depth) = and ELC (Entropy Label Capability) of a node or link. " However, there = is no extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now?


GV> = I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW.  If for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 we just need node based ERLD, then I that is just fine. My = personal opinion is that we need node ERLD for node for sure in BGP-LS, = and that link ERLD is a nice to have. It seems relative easy and = pragmatic to add both Link and node ERLD in current version of the = BGP-LS ERLD document.

3) It said "...if a network = SDN controller is connected to the network through a BGP-LS session and = not through ISIS or OSPF technology, then both RLD and ELC needs to be = signaled in BGP-LS accordingly.  This document describes the = extension BGP-LS requires to transport the combination of RLD and ELC = into according ERLD attributes for nodes and links..." I have not yet = found any explanation about the motivation for advertising the = combination of RLD and ELC into according ERLD attributes rather than = advertising these two attributes separately. Would it be better to give = any explanation about such motivation in the Problem Statement = section?



GV> = Yes, indeed, again that was reason again that the work was presented = during IETF100 as I had some doubts myself. During IETF100 IDR meeting, = I learned and was confirmed that ERLD is now in the SPRING entropy label = draft and that hence ERLD is to be signalled for the most prominent = use-case driving readable label depth signalling
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. I see no reason to open that discussion again, and current = BGP-LS ERLD draft is inline the most dominant use-case scenario (Entropy = based load-balancing). I could change the existing text to refer = to https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 and only mention ERLD (and no longer mention ELC/RLD at = all) if IDR WG find that better?

Brgds,

G/

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg = (ginsberg); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Xu,

I am arguing the exact opposite of what = you are saying.

Let us leave ELC/ERLD aside = since it is very limited to entropy label use-case and
the = proposed IGP/BGP-LS encoding is very specific to that. I am not sure if = this is
the time anymore to revisit that.

The MSD proposal came later and I support is since I've found = its use to be
much more widespread and the proposed = IGP/BGP-LS protocol encoding to be
very efficient as an = implementer of these protocols. Hence the request to not
restrict it to "writable" or "imposition" cases solely. It is = also not just about
"readability" - which by itself is = pretty meaningless. Even ERLD is about
"reading" and then = "doing *something specific* about it" as discussed in
ietf-spring-segment-routing-mpls.

There is no second thoughts about the IGP ELC drafts and they = are very useful
and necessary. Just to be clear there is = *no functional or operational change*
that I am arguing = for here. The discussion is purely on the way to handle these
encodings and whether we can use the MSD mechanism in a = generalized
manner.

Thanks,
Ketan

-----Original = Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: 21 = December 2017 08:10
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; = Ketan Talaulikar (ketant)
<ketant@cisco.com>; = Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Les,

If I understand it correctly, the MSD = concept was originated from
(https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#p= age-7) as
described below:

"The "Maximum SID Depth" (1
  octet) = field (MSD) specifies the maximum number of SIDs (MPLS label
  stack depth in the context of this document) = that a PCC is capable of
  imposing on a = packet."

Before considering expanding the = semantics of the MSD concept as defined in
the above = PCE-SR draft, how about first considering renaming the capability of
imposing the maximum number of labels so as to eliminate = possible confusions,
e.g., Writable Label-stack Depth = (WLD) as opposed to the Readable Label-stack
Depth (RLD) = as defined in (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) = ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les = Ginsberg
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); = Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Ketan -

Thanx for the = comments.
I think we do want to allow MSD support for = values other than
imposition values. We will revise the = text so we are not restricted to only
imposition cases.

 Les


-----Original Message-----
From: Ketan = Talaulikar (ketant)
Sent: Wednesday, December 20, 2017 = 1:51 AM
To: Christian Hopps <chopps@chopps.org>; = isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Hello,

I support this document = and would like to ask the authors and WG to
consider if we = can expand the scope of this draft to not just
"imposition" = of the SID stack but also other similar limits related
to = other
actions (e.g.
reading, processing, etc.). With Segment = Routing, we are coming
across various actions that nodes = need to do with the SID stack for
different purposes and = IMHO it would be useful to extend the MSD
ability to cover = those as they arise.

Thanks,
Ketan

-----Original = Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian Hopps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are starting = a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routin= g-msd
/

which will last = an extended 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3D= draft-ietf-
is
is-
segment-routing-msd

Authors = please reply to the list indicating whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_____________________________________= __________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

= --Apple-Mail=_AD9F1F8B-A08B-4C58-91FE-2EE280812CB2-- From nobody Sat Dec 23 11:09:46 2017 Return-Path: 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 B3BFC124D68; Sat, 23 Dec 2017 11:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 gjOBNvFz4KQT; Sat, 23 Dec 2017 11:09:22 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 245B91241F3; Sat, 23 Dec 2017 11:09:22 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id f190so17843003ita.5; Sat, 23 Dec 2017 11:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xa0mC6u00KNW5iQ/ShKj2Wq/dfiFeCW3e195cKj2Gv0=; b=OnkWiVnp88lZo2KC1Dv5UyhR8TtEtOlGH4DosThnNSR68SgFuFIPByBxnUSfTapQKl LHIUueUwWfL16vGHOPReIyXHjBPgufLR0AHlcfYOYKxQjOkVSO4ghvr2OFLS6n/COawy AhzEqacFWFloiHYMdjLdmyfEIBpbZvac0OGevpWRV6gIcZQfZZd9sJzctNUDnuKdNa5Y KtY23CoTwoq/g5ncYLlccdHBVFX7FFTVZhEyKtlMYNEkXjYvWlcxQPdCstsAhRW72Lrz Giay5gxwgappHJcZSOSXeSq/wbbxJ26EM1qMf/R1uhDZhiIjJoxIJnaQgs0SA/05Ez77 0ctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xa0mC6u00KNW5iQ/ShKj2Wq/dfiFeCW3e195cKj2Gv0=; b=pwFPvTWWjnfTDs62V7cz2pjarvtircxJTi2iLzKSiUpNpgpetT8a5zQ5S7Xb7kZ48H BgQ+qspwB6algaKIhOX6rEGZ2Dsyc0VV7dyy5RRfwZ6ReYjTMxdOlSXzTibfnkVUPpnz mLqOjX1vFqwINwXf6Drv0LnISDjpsd3ki13lEvuxf6ymfdoQesx3X8YTgqxnD9mrncdt oirMCzOLGRWSCY7hx/9MHY59jeaTPNm2EX8hSTjLPqbSX+F9i9AjoLgn7rIMbiyKxUUE kQvR0rJLBtMzO9m9lMTWBM/vs3dtwoWgt5c6eA8rrSp+l+9KxfxopAKRmafch32vN5GY ev4Q== X-Gm-Message-State: AKGB3mIlk5Jsy6SMcdIjtfNykaFPDePCqax9XAqK+8cZRRa9yYFgHbJL 6MiU+gM4ajQ2xyYLs2721OtQkrri X-Google-Smtp-Source: ACJfBotVHv2H3XmYklw6MyxXxt3T2vEyZKbw6qFvZSbVu+MqgA1JMiZG3CPlSIyjOu15HQiF3lJSeg== X-Received: by 10.36.181.82 with SMTP id j18mr23668289iti.18.1514056161274; Sat, 23 Dec 2017 11:09:21 -0800 (PST) Received: from ?IPv6:2600:6c4e:2200:4cb:ac55:5e66:96a2:7f99? (2600-6c4e-2200-04cb-ac55-5e66-96a2-7f99.dhcp6.chtrptr.net. [2600:6c4e:2200:4cb:ac55:5e66:96a2:7f99]) by smtp.gmail.com with ESMTPSA id b12sm3222329ioe.38.2017.12.23.11.09.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Dec 2017 11:09:20 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sat, 23 Dec 2017 11:09:18 -0800 Cc: Xuxiaohu , "idr@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> To: Gunter Van De Velde Archived-At: Subject: Re: [Idr] [OSPF] A comment regarding the relationship between RLD and ERLD X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 19:09:26 -0000 --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gunter, As I also said in Singapore - another interesting use case would be related t= o statistics, without going into semantics, we might need another SID in the= stack to uniquely identify a tunnel (domain wide)that would result in a cou= nter hit. RLD is crucial here. There would be some control plan implications on how to correlate local coun= ter name to domain wide tunnel identifier. Some YANG work as well (streaming= telemetry related). Happy Holidays everyone! Regards, Jeff > On Dec 23, 2017, at 01:25, Gunter Van De Velde wrote: >=20 > Hi Xiaohu, >=20 > Thanks for digging through the draft. >=20 > See inline: GV> >=20 >> On 23 Dec 2017, at 09:40, Xuxiaohu wrote: >>=20 >> Hi all, >>=20 >> I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) due to t= he curiosity of the ERLD terminology. I have thought that this draft is just= about a straightforward BGP-LS extension for the RLD concept as defined in d= raft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the draft n= ame. However it isn't in fact. Maybe the draft name should have been *-erld r= ather than *-rld. >>=20 >> I have the following comments on this draft (draft-ietf-idr-bgp-ls-segmen= t-routing-rld): >>=20 >> 1) ERLD means Entropy capable Readable Label Depth as defined in this dra= ft. However, it said "...A network node signalling an ERLD MUST support the a= bility to read the signalled number of labels before any action is done upon= the packet..." I'm wondering what actions other than the EL-based LB action= the "any action" could be since the ERLD has been tightly coupled with the E= L-based LB mechanism. In contrast, the RLD as defined in the two IGP drafts i= s not tightly couple with the EL-based LB action. In other words, the RLD ca= pability could be applicable to other use cases besides the EL-based LB. >>=20 >=20 > GV> This is exactly what I asked during the IETF100 IDR slot when I presen= ted the updated work. The consensus was that signalling of a readable label d= epth has entropy as the dominant use-case scenario. This is now documented i= n:=20 > https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. Conse= nsus from IETF100 IDR meeting was that ERLD is the way forward for BGP-LS ba= sed signalling, and that maybe this should also be the case for both ISIS an= d OSPF drafts (however, that is different discussion). I agree with IDR con= sensus and it seems the most pragmatic path forward. >=20 >=20 >> 2) It said "...In existing technology both ISIS [4] and OSPF [3] have pro= posed extensions to signal the RLD (Readable Label Depth) and ELC (Entropy L= abel Capability) of a node or link. " However, there is no extensions to sig= nal the RLD and ELC of a link, if I remembered correctly as a co-author of t= he above two IGP drafts:) In fact, when the two IGP drafts were initially pr= oposed, some guys does argue why not advertise ELC and RLD of the per-link g= ranularity as well. After some discussion in IETF, a rough consensus had bee= n reached that the advertisement of ELC and RLD at a per node granularity wa= s good enough at that time. That's the reason why the two IGP drafts had not= been extended to advertise ELC and RLD at a per link granularity therefore.= Maybe we should reopen such discussion now? >>=20 >=20 > GV> I have no intend to open up that discussion at all, as it seems a prag= matic consensus was reached. Steering seems to become more complex when link= based ERLD is proposed and a potential set of different ERLDs are signalled= due to capabilities of the line-card HW. If for https://tools.ietf.org/htm= l/draft-ietf-mpls-spring-entropy-label-07 we just need node based ERLD, then= I that is just fine. My personal opinion is that we need node ERLD for node= for sure in BGP-LS, and that link ERLD is a nice to have. It seems relative= easy and pragmatic to add both Link and node ERLD in current version of the= BGP-LS ERLD document. >=20 >> 3) It said "...if a network SDN controller is connected to the network th= rough a BGP-LS session and not through ISIS or OSPF technology, then both RL= D and ELC needs to be signaled in BGP-LS accordingly. This document describ= es the extension BGP-LS requires to transport the combination of RLD and ELC= into according ERLD attributes for nodes and links..." I have not yet found= any explanation about the motivation for advertising the combination of RLD= and ELC into according ERLD attributes rather than advertising these two at= tributes separately. Would it be better to give any explanation about such m= otivation in the Problem Statement section? >>=20 >>=20 >=20 > GV> Yes, indeed, again that was reason again that the work was presented d= uring IETF100 as I had some doubts myself. During IETF100 IDR meeting, I lea= rned and was confirmed that ERLD is now in the SPRING entropy label draft an= d that hence ERLD is to be signalled for the most prominent use-case driving= readable label depth signalling > https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. I see= no reason to open that discussion again, and current BGP-LS ERLD draft is i= nline the most dominant use-case scenario (Entropy based load-balancing). I c= ould change the existing text to refer to https://tools.ietf.org/html/draft-= ietf-mpls-spring-entropy-label-07 and only mention ERLD (and no longer menti= on ELC/RLD at all) if IDR WG find that better? >=20 > Brgds, >=20 > G/ >=20 >> Best regards, >> Xiaohu >>=20 >>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@ci= sco.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 12:16 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); Christia= n Hopps; isis-wg@ietf.org >>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-m= sd@ietf.org >>> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for draft-ietf-isis-segme= nt-routing-msd-07 >>>=20 >>> Hi Xu, >>>=20 >>> I am arguing the exact opposite of what you are saying. >>>=20 >>> Let us leave ELC/ERLD aside since it is very limited to entropy label us= e-case and >>> the proposed IGP/BGP-LS encoding is very specific to that. I am not sure= if this is >>> the time anymore to revisit that. >>>=20 >>> The MSD proposal came later and I support is since I've found its use to= be >>> much more widespread and the proposed IGP/BGP-LS protocol encoding to be= >>> very efficient as an implementer of these protocols. Hence the request t= o not >>> restrict it to "writable" or "imposition" cases solely. It is also not j= ust about >>> "readability" - which by itself is pretty meaningless. Even ERLD is abou= t >>> "reading" and then "doing *something specific* about it" as discussed in= >>> ietf-spring-segment-routing-mpls. >>>=20 >>> There is no second thoughts about the IGP ELC drafts and they are very u= seful >>> and necessary. Just to be clear there is *no functional or operational c= hange* >>> that I am arguing for here. The discussion is purely on the way to handl= e these >>> encodings and whether we can use the MSD mechanism in a generalized >>> manner. >>>=20 >>> Thanks, >>> Ketan >>>=20 >>> -----Original Message----- >>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com] >>> Sent: 21 December 2017 08:10 >>> To: Les Ginsberg (ginsberg) ; Ketan Talaulikar (keta= nt) >>> ; Christian Hopps ; isis-wg@ietf.or= g >>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for draft-ietf-isis-= segment-routing-msd-07 >>>=20 >>> Hi Les, >>>=20 >>> If I understand it correctly, the MSD concept was originated from >>> (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7) a= s >>> described below: >>>=20 >>> "The "Maximum SID Depth" (1 >>> octet) field (MSD) specifies the maximum number of SIDs (MPLS label >>> stack depth in the context of this document) that a PCC is capable of >>> imposing on a packet." >>>=20 >>> Before considering expanding the semantics of the MSD concept as defined= in >>> the above PCE-SR draft, how about first considering renaming the capabil= ity of >>> imposing the maximum number of labels so as to eliminate possible confus= ions, >>> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-= stack >>> Depth (RLD) as defined in (https://tools.ietf.org/html/draft-ietf-ospf-m= pls-elc) >>> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) ? >>>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Les Ginsberg >>>> (ginsberg) >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5= 4:02 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian Hopps= ; isis-wg@ietf.org >>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-= msd@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>>> draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Ketan - >>>>=20 >>>> Thanx for the comments. >>>> I think we do want to allow MSD support for values other than >>>> imposition values. We will revise the text so we are not restricted to o= nly >>> imposition cases. >>>>=20 >>>> Les >>>>=20 >>>>=20 >>>>> -----Original Message----- >>>>> From: Ketan Talaulikar (ketant) >>>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>>> To: Christian Hopps ; isis-wg@ietf.org >>>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>>> Subject: RE: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>> Hello, >>>>>=20 >>>>> I support this document and would like to ask the authors and WG to >>>>> consider if we can expand the scope of this draft to not just >>>>> "imposition" of the SID stack but also other similar limits related >>>>> to other >>>> actions (e.g. >>>>> reading, processing, etc.). With Segment Routing, we are coming >>>>> across various actions that nodes need to do with the SID stack for >>>>> different purposes and IMHO it would be useful to extend the MSD >>>>> ability to cover those as they arise. >>>>>=20 >>>>> Thanks, >>>>> Ketan >>>>>=20 >>>>> -----Original Message----- >>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of >>>>> Christian Hopps >>>>> Sent: 20 December 2017 14:03 >>>>> To: isis-wg@ietf.org >>>>> Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org >>>>> Subject: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>>=20 >>>>> The authors have asked for and we are starting a WG Last Call on >>>>>=20 >>>>>=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd >>>>> / >>>>>=20 >>>>> which will last an extended 4 weeks to allow for year-end PTO patterns= . >>>>>=20 >>>>> An IPR statement exists: >>>>>=20 >>>>>=20 >>>>> https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-iet= f- >>>>> is >>>>> is- >>>>> segment-routing-msd >>>>>=20 >>>>> Authors please reply to the list indicating whether you are aware of >>>>> any >>>>> *new* IPR. >>>>>=20 >>>>> Thanks, >>>>> Chris. >>>>>=20 >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg >>>>=20 >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Gunter,

As I also said i= n Singapore - another interesting use case would be related to statistics, w= ithout going into semantics, we might need another SID in the stack to uniqu= ely identify a tunnel (domain wide)that would result in a counter hit. RLD i= s crucial here.
There would be some control plan implications on h= ow to correlate local counter name to domain wide tunnel identifier. Some YA= NG work as well (streaming telemetry related).

Happ= y Holidays everyone!

Regards,
Jeff=

On Dec 23, 2017, at 01:25, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:

Hi Xiaohu,

Thanks for digging through the draft= .

See inline: GV&g= t;

On 23 Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi all,
I just read the draft (draft-ietf-idr-bgp-ls-seg= ment-routing-rld) due to the curiosity of the ERLD terminology. I have thoug= ht that this draft is just about a straightforward BGP-LS extension for the R= LD concept as defined in draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-e= lc according to the draft name. However it isn't in fact. Maybe the draft na= me should have been *-erld rather than *-rld.

I= have the following comments on this draft (draft-ietf-idr-bgp-ls-segment-ro= uting-rld):

1) ERLD means Entropy capable Reada= ble Label Depth as defined in this draft. However, it said "...A network nod= e signalling an ERLD MUST support the ability to read the signalled number o= f labels before any action is done upon the packet..." I'm wondering what ac= tions other than the EL-based LB action the "any action" could be since the E= RLD has been tightly coupled with the EL-based LB mechanism. In contrast, th= e RLD as defined in the two IGP drafts is not tightly couple with the EL-bas= ed LB action. In other words, the RLD capability could be applicable to othe= r use cases besides the EL-based LB.


GV> This is exactly what I a= sked during the IETF100 IDR slot when I presented the updated work. The cons= ensus was that signalling of a readable label depth has entropy as the domin= ant use-case scenario. This is now documented in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07. C= onsensus from IETF100 IDR meeting was that ERLD is the way forward for BGP-L= S based signalling, and that maybe this should also be the case for both ISI= S and OSPF drafts (however, that is different discussion).  I agree wit= h IDR consensus and it seems the most pragmatic path forward.


2) It said "...In existing technology both ISIS [4] a= nd OSPF [3] have proposed extensions to signal the RLD (Readable Label Depth= ) and ELC (Entropy Label Capability) of a node or link. " However, there is n= o extensions to signal the RLD and ELC of a link, if I remembered correctly a= s a co-author of the above two IGP drafts:) In fact, when the two IGP drafts= were initially proposed, some guys does argue why not advertise ELC and RLD= of the per-link granularity as well. After some discussion in IETF, a rough= consensus had been reached that the advertisement of ELC and RLD at a per n= ode granularity was good enough at that time. That's the reason why the two I= GP drafts had not been extended to advertise ELC and RLD at a per link granu= larity therefore. Maybe we should reopen such discussion now?
=

GV>= ; I have no intend to open up that discussion at all, as it seems a pragmati= c consensus was reached. Steering seems to become more complex when link bas= ed ERLD is proposed and a potential set of different ERLDs are signalled due= to capabilities of the line-card HW.  If for https://to= ols.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 we just need n= ode based ERLD, then I that is just fine. My personal opinion is that we nee= d node ERLD for node for sure in BGP-LS, and that link ERLD is a nice to hav= e. It seems relative easy and pragmatic to add both Link and node ERLD in cu= rrent version of the BGP-LS ERLD document.

3) It said "...if a n= etwork SDN controller is connected to the network through a BGP-LS session a= nd not through ISIS or OSPF technology, then both RLD and ELC needs to be si= gnaled in BGP-LS accordingly.  This document describes the extension BG= P-LS requires to transport the combination of RLD and ELC into according ERL= D attributes for nodes and links..." I have not yet found any explanation ab= out the motivation for advertising the combination of RLD and ELC into accor= ding ERLD attributes rather than advertising these two attributes separately= . Would it be better to give any explanation about such motivation in the Pr= oblem Statement section?


<= /div>

GV> Yes, indeed, again t= hat was reason again that the work was presented during IETF100 as I had som= e doubts myself. During IETF100 IDR meeting, I learned and was confirmed tha= t ERLD is now in the SPRING entropy label draft and that hence ERLD is to be= signalled for the most prominent use-case driving readable label depth sign= alling
https://tools.ietf.org/html/draft-ietf-mpls-= spring-entropy-label-07. I see no reason to open that discussion again, a= nd current BGP-LS ERLD draft is inline the most dominant use-case scenario (= Entropy based load-balancing). I could change the existing text to refer to&= nbsp;https://tools.ietf.org/html/draft-ietf-mpls-spring-entro= py-label-07 and only mention ERLD (and no longer mention ELC/RLD at= all) if IDR WG find that better?

Brgds,=

G/

Best regards,
Xiaohu

= -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB= =B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6= =94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); Christian Hopps= ; isis-wg@ietf.org
=E6=8A=84=E9=80=81: = isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for draft-ietf-isis-= segment-routing-msd-07

Hi Xu,
I am arguing the exact opposite of what you are saying.

Let us leave ELC/ERLD aside since it is very limited to= entropy label use-case and
the proposed IGP/BGP-LS encoding i= s very specific to that. I am not sure if this is
the time any= more to revisit that.

The MSD proposal came lat= er and I support is since I've found its use to be
much more w= idespread and the proposed IGP/BGP-LS protocol encoding to be
= very efficient as an implementer of these protocols. Hence the request to no= t
restrict it to "writable" or "imposition" cases solely. It i= s also not just about
"readability" - which by itself is prett= y meaningless. Even ERLD is about
"reading" and then "doing *s= omething specific* about it" as discussed in
ietf-spring-segme= nt-routing-mpls.

There is no second thoughts ab= out the IGP ELC drafts and they are very useful
and necessary.= Just to be clear there is *no functional or operational change*
that I am arguing for here. The discussion is purely on the way to handle= these
encodings and whether we can use the MSD mechanism in a= generalized
manner.

Thanks,
Ketan

-----Original Message-----
From: Xuxiaohu [= mailto:xuxiaohu@huawei.com]
Sent: 21 December 2017 08:10To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Ketan Talaulikar (ketant)
<ketant@cisco.co= m>; Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.o= rg
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for= draft-ietf-isis-segment-routing-msd-07

Hi Les,=

If I understand it correctly, the MSD concept w= as originated from
(https://tools.ietf.org/htm= l/draft-ietf-pce-segment-routing-11#page-7) as
described b= elow:

"The "Maximum SID Depth" (1
  octet) field (MSD) specifies the maximum number of SIDs (MPLS l= abel
  stack depth in the context of this document)= that a PCC is capable of
  imposing on a packet."<= br class=3D"">
Before considering expanding the semantics of t= he MSD concept as defined in
the above PCE-SR draft, how about= first considering renaming the capability of
imposing the max= imum number of labels so as to eliminate possible confusions,
= e.g., Writable Label-stack Depth (WLD) as opposed to the Readable Label-stac= k
Depth (RLD) as defined in (https://tools.ietf.org/html/draft= -ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draf= t-ietf-isis-mpls-elc) ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91= =E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les Ginsberg=
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4= =BA=BA: Ketan Talaulikar (ketant); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81= : isis-ads@ietf.org; draft= -ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98= : Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routi= ng-msd-07

Ketan -

= Thanx for the comments.
I think we do want to allow MSD suppor= t for values other than
imposition values. We will revise the t= ext so we are not restricted to only
imposition c= ases.

&nb= sp;Les


-----Original Message-----
From: Ketan Talaulikar (= ketant)
Sent: Wednesday, December 20, 2017 1:51 AM
To: Christian Hopps <c= hopps@chopps.org>; isi= s-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft= -ietf-isis-segment-routing-msd-07

Hello,

I support this document and would like to ask the aut= hors and WG to
consider if we can expand the scope of this dra= ft to not just
"imposition" of the SID stack but also other si= milar limits related
to other
actio= ns (e.g.
reading, process= ing, etc.). With Segment Routing, we are coming
across various= actions that nodes need to do with the SID stack for
differen= t purposes and IMHO it would be useful to extend the MSD
abili= ty to cover those as they arise.

Thanks,
Ketan

-----Original Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian H= opps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: <= a href=3D"mailto:isis-ads@ietf.org" class=3D"">isis-ads@ietf.org; draft-i= etf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] W= G Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are s= tarting a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-m= sd
/

which will last an exten= ded 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraf= t-ietf-
is
is-
segment-routing= -msd

Authors please reply to the list indicatin= g whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mai= ling list
Isis-wg@ietf.org=
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg<= br class=3D"">
____________________________________= ___________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

<= /blockquote>
= --Apple-Mail-7029ADBD-356B-4FB7-8C63-2DC25D74CCC8-- From nobody Sat Dec 23 12:08:02 2017 Return-Path: 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 A9F5612025C; Sat, 23 Dec 2017 12:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.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 jCZUdECN_wiW; Sat, 23 Dec 2017 12:07:49 -0800 (PST) Received: from st13p11im-asmtp004.me.com (st13p11im-asmtp004.me.com [17.164.40.219]) (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 BD2371200F3; Sat, 23 Dec 2017 12:07:49 -0800 (PST) Received: from process-dkim-sign-daemon.st13p11im-asmtp004.me.com by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P1F00600JR7NS00@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1514059668; bh=oB6mn4ivHya0wBcQaVYdbwjMxTU5JECQKTM7tUHprcY=; h=From:Message-id:Content-type:MIME-version:Subject:Date:To; b=E9WKQDGPkcLc9sz9Z437p+JzmDsSbihNau0dwwFW7V3icNZMPGwK4yn3pbXzd1al5 /WjnPvL67a04iXKLSN1KTevGh5sDePeXAodu85Y+MjQdLc4/iGZLQfz/0Yi6zh4u0e X8vLhsSwDFBWNiD8+29Tu//T0ToPqHYOMYmylFASuiHmUFOA8lc9f8nyGfVgoCvVDQ 2qDhMcJ8m3PlyQDJ7mtD/L9Vu5PVIoorMt27mRbFD2b/OHCuo3uTbMuySK2sfxR+ff FD1RE0VHGX/PSlfFWamkv52lxlJK092zTAYIDQyi71MuU5s3YXkzdYi6F4vXb7fbOg gn5Lw1lrwkDiw== Received: from icloud.com ([127.0.0.1]) by st13p11im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P1F001JRJWQIN30@st13p11im-asmtp004.me.com>; Sat, 23 Dec 2017 20:07:43 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-12-23_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=3 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1712230277 From: Gunter Van De Velde Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD" MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sat, 23 Dec 2017 21:07:38 +0100 In-reply-to: Cc: Xuxiaohu , "idr@ietf.org" , "spring@ietf.org" , "isis-wg@ietf.org" , "ospf@ietf.org" To: Jeff Tantsura References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE304A7A3E@NKGEML515-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Idr] [OSPF] A comment regarding the relationship between RLD and ERLD X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 20:07:53 -0000 --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeff, Correct. I referenced below to =E2=80=98dominant use cases being = entropy=E2=80=9D for a reason. There is indeed use case regarding alternate marking using Synonymous = Flow Labels and another one involving=20 potential statistics marking using targeted labels. This understanding = drove to question at IETF100 IDR meeting to=20 go for either =E2=80=9CERLD=E2=80=9D or =E2=80=9CRLD/ELC=E2=80=9D (or = even additional capabilities signalled).=20 The consensus at IDR@IETF100 was that dominant use-case is entropy and = that ERLD is the logical info to signal in BGP-LS.=20 I had/have no strong bias with going either way. I just am little = dazzled that for some reason the discussion is opened up again now we = had consensus. G/ > On 23 Dec 2017, at 20:09, Jeff Tantsura = wrote: >=20 > Gunter, >=20 > As I also said in Singapore - another interesting use case would be = related to statistics, without going into semantics, we might need = another SID in the stack to uniquely identify a tunnel (domain wide)that = would result in a counter hit. RLD is crucial here. > There would be some control plan implications on how to correlate = local counter name to domain wide tunnel identifier. Some YANG work as = well (streaming telemetry related). >=20 > Happy Holidays everyone! >=20 > Regards, > Jeff >=20 > On Dec 23, 2017, at 01:25, Gunter Van De Velde = > = wrote: >=20 >> Hi Xiaohu, >>=20 >> Thanks for digging through the draft. >>=20 >> See inline: GV> >>=20 >>> On 23 Dec 2017, at 09:40, Xuxiaohu > wrote: >>>=20 >>> Hi all, >>>=20 >>> I just read the draft (draft-ietf-idr-bgp-ls-segment-routing-rld) = due to the curiosity of the ERLD terminology. I have thought that this = draft is just about a straightforward BGP-LS extension for the RLD = concept as defined in draft-ietf-ospf-mpls-elc and = draft-ietf-isis-mpls-elc according to the draft name. However it isn't = in fact. Maybe the draft name should have been *-erld rather than *-rld. >>>=20 >>> I have the following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld): >>>=20 >>> 1) ERLD means Entropy capable Readable Label Depth as defined in = this draft. However, it said "...A network node signalling an ERLD MUST = support the ability to read the signalled number of labels before any = action is done upon the packet..." I'm wondering what actions other than = the EL-based LB action the "any action" could be since the ERLD has been = tightly coupled with the EL-based LB mechanism. In contrast, the RLD as = defined in the two IGP drafts is not tightly couple with the EL-based LB = action. In other words, the RLD capability could be applicable to other = use cases besides the EL-based LB. >>>=20 >>=20 >> GV> This is exactly what I asked during the IETF100 IDR slot when I = presented the updated work. The consensus was that signalling of a = readable label depth has entropy as the dominant use-case scenario. This = is now documented in:=20 >> https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . = Consensus from IETF100 IDR meeting was that ERLD is the way forward for = BGP-LS based signalling, and that maybe this should also be the case for = both ISIS and OSPF drafts (however, that is different discussion). I = agree with IDR consensus and it seems the most pragmatic path forward. >>=20 >>=20 >>> 2) It said "...In existing technology both ISIS [4] and OSPF [3] = have proposed extensions to signal the RLD (Readable Label Depth) and = ELC (Entropy Label Capability) of a node or link. " However, there is no = extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now? >>>=20 >>=20 >> GV> I have no intend to open up that discussion at all, as it seems a = pragmatic consensus was reached. Steering seems to become more complex = when link based ERLD is proposed and a potential set of different ERLDs = are signalled due to capabilities of the line-card HW. If for = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = we = just need node based ERLD, then I that is just fine. My personal opinion = is that we need node ERLD for node for sure in BGP-LS, and that link = ERLD is a nice to have. It seems relative easy and pragmatic to add both = Link and node ERLD in current version of the BGP-LS ERLD document. >>=20 >>> 3) It said "...if a network SDN controller is connected to the = network through a BGP-LS session and not through ISIS or OSPF = technology, then both RLD and ELC needs to be signaled in BGP-LS = accordingly. This document describes the extension BGP-LS requires to = transport the combination of RLD and ELC into according ERLD attributes = for nodes and links..." I have not yet found any explanation about the = motivation for advertising the combination of RLD and ELC into according = ERLD attributes rather than advertising these two attributes separately. = Would it be better to give any explanation about such motivation in the = Problem Statement section? >>>=20 >>>=20 >>=20 >> GV> Yes, indeed, again that was reason again that the work was = presented during IETF100 as I had some doubts myself. During IETF100 IDR = meeting, I learned and was confirmed that ERLD is now in the SPRING = entropy label draft and that hence ERLD is to be signalled for the most = prominent use-case driving readable label depth signalling >> https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = . I = see no reason to open that discussion again, and current BGP-LS ERLD = draft is inline the most dominant use-case scenario (Entropy based = load-balancing). I could change the existing text to refer to = https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-07 = = and only mention ERLD (and no longer mention ELC/RLD at all) if IDR WG = find that better? >>=20 >> Brgds, >>=20 >> G/ >>=20 >>> Best regards, >>> Xiaohu >>>=20 >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) = [mailto:ketant@cisco.com ] >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 12:16 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg (ginsberg); = Christian Hopps; isis-wg@ietf.org >>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>> =E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hi Xu, >>>>=20 >>>> I am arguing the exact opposite of what you are saying. >>>>=20 >>>> Let us leave ELC/ERLD aside since it is very limited to entropy = label use-case and >>>> the proposed IGP/BGP-LS encoding is very specific to that. I am not = sure if this is >>>> the time anymore to revisit that. >>>>=20 >>>> The MSD proposal came later and I support is since I've found its = use to be >>>> much more widespread and the proposed IGP/BGP-LS protocol encoding = to be >>>> very efficient as an implementer of these protocols. Hence the = request to not >>>> restrict it to "writable" or "imposition" cases solely. It is also = not just about >>>> "readability" - which by itself is pretty meaningless. Even ERLD is = about >>>> "reading" and then "doing *something specific* about it" as = discussed in >>>> ietf-spring-segment-routing-mpls. >>>>=20 >>>> There is no second thoughts about the IGP ELC drafts and they are = very useful >>>> and necessary. Just to be clear there is *no functional or = operational change* >>>> that I am arguing for here. The discussion is purely on the way to = handle these >>>> encodings and whether we can use the MSD mechanism in a generalized >>>> manner. >>>>=20 >>>> Thanks, >>>> Ketan >>>>=20 >>>> -----Original Message----- >>>> From: Xuxiaohu [mailto:xuxiaohu@huawei.com = ] >>>> Sent: 21 December 2017 08:10 >>>> To: Les Ginsberg (ginsberg) >; Ketan Talaulikar (ketant) >>>> >; Christian Hopps = >; isis-wg@ietf.org = >>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>> Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07 >>>>=20 >>>> Hi Les, >>>>=20 >>>> If I understand it correctly, the MSD concept was originated from >>>> = (https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#page-7 = ) = as >>>> described below: >>>>=20 >>>> "The "Maximum SID Depth" (1 >>>> octet) field (MSD) specifies the maximum number of SIDs (MPLS = label >>>> stack depth in the context of this document) that a PCC is = capable of >>>> imposing on a packet." >>>>=20 >>>> Before considering expanding the semantics of the MSD concept as = defined in >>>> the above PCE-SR draft, how about first considering renaming the = capability of >>>> imposing the maximum number of labels so as to eliminate possible = confusions, >>>> e.g., Writable Label-stack Depth (WLD) as opposed to the Readable = Label-stack >>>> Depth (RLD) as defined in = (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc = ) >>>> and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc = ) ? >>>>=20 >>>> Best regards, >>>> Xiaohu >>>>=20 >>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg = [mailto:isis-wg-bounces@ietf.org ] = =E4=BB=A3=E8=A1=A8 Les Ginsberg >>>>> (ginsberg) >>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97= =A5 4:02 >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); Christian = Hopps; isis-wg@ietf.org >>>>> =E6=8A=84=E9=80=81: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>> =E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for >>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>=20 >>>>> Ketan - >>>>>=20 >>>>> Thanx for the comments. >>>>> I think we do want to allow MSD support for values other than >>>>> imposition values. We will revise the text so we are not = restricted to only >>>> imposition cases. >>>>>=20 >>>>> Les >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ketan Talaulikar (ketant) >>>>>> Sent: Wednesday, December 20, 2017 1:51 AM >>>>>> To: Christian Hopps >; isis-wg@ietf.org >>>>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>>> Subject: RE: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> I support this document and would like to ask the authors and WG = to >>>>>> consider if we can expand the scope of this draft to not just >>>>>> "imposition" of the SID stack but also other similar limits = related >>>>>> to other >>>>> actions (e.g. >>>>>> reading, processing, etc.). With Segment Routing, we are coming >>>>>> across various actions that nodes need to do with the SID stack = for >>>>>> different purposes and IMHO it would be useful to extend the MSD >>>>>> ability to cover those as they arise. >>>>>>=20 >>>>>> Thanks, >>>>>> Ketan >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org = ] On Behalf Of >>>>>> Christian Hopps >>>>>> Sent: 20 December 2017 14:03 >>>>>> To: isis-wg@ietf.org >>>>>> Cc: isis-ads@ietf.org ; = draft-ietf-isis-segment-routing-msd@ietf.org = >>>>>> Subject: [Isis-wg] WG Last Call for >>>>>> draft-ietf-isis-segment-routing-msd-07 >>>>>>=20 >>>>>>=20 >>>>>> The authors have asked for and we are starting a WG Last Call on >>>>>>=20 >>>>>>=20 >>>>>> = https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd = >>>>>> / >>>>>>=20 >>>>>> which will last an extended 4 weeks to allow for year-end PTO = patterns. >>>>>>=20 >>>>>> An IPR statement exists: >>>>>>=20 >>>>>>=20 >>>>>> = https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3Ddraft-ietf- = = >>>>>> is >>>>>> is- >>>>>> segment-routing-msd >>>>>>=20 >>>>>> Authors please reply to the list indicating whether you are aware = of >>>>>> any >>>>>> *new* IPR. >>>>>>=20 >>>>>> Thanks, >>>>>> Chris. >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Isis-wg mailing list >>>>>> Isis-wg@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/isis-wg = >>>>>=20 >>>>> _______________________________________________ >>>>> Isis-wg mailing list >>>>> Isis-wg@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/isis-wg = >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr = >>=20 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf = --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jeff,

Correct. I = referenced below to =E2=80=98dominant use cases being entropy=E2=80=9D = for a reason.

There is indeed use case regarding alternate marking using = Synonymous Flow Labels and another one involving 
potential statistics marking using targeted labels. This = understanding drove to question at IETF100 IDR meeting = to 
go for either =E2=80=9CERLD=E2=80=9D or = =E2=80=9CRLD/ELC=E2=80=9D (or even additional capabilities = signalled). 

The consensus at IDR@IETF100 was that dominant use-case is = entropy and that ERLD is the logical info to signal in = BGP-LS. 
I had/have no strong bias with going = either way. I just am little dazzled that for some reason the discussion = is opened up again now we had consensus.

G/

On 23 = Dec 2017, at 20:09, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

Gunter,
As I also said in Singapore = - another interesting use case would be related to statistics, without = going into semantics, we might need another SID in the stack to uniquely = identify a tunnel (domain wide)that would result in a counter hit. RLD = is crucial here.
There would be some control = plan implications on how to correlate local counter name to domain wide = tunnel identifier. Some YANG work as well (streaming telemetry = related).

Happy Holidays everyone!

Regards,
Jeff

On Dec 23, 2017, at 01:25, Gunter Van De Velde <guntervandeveldecc@icloud.com> wrote:

Hi = Xiaohu,

Thanks for = digging through the draft.

See inline: GV>

On 23 = Dec 2017, at 09:40, Xuxiaohu <xuxiaohu@huawei.com> wrote:

Hi = all,

I just read the draft = (draft-ietf-idr-bgp-ls-segment-routing-rld) due to the curiosity of the = ERLD terminology. I have thought that this draft is just about a = straightforward BGP-LS extension for the RLD concept as defined in = draft-ietf-ospf-mpls-elc and draft-ietf-isis-mpls-elc according to the = draft name. However it isn't in fact. Maybe the draft name should have = been *-erld rather than *-rld.

I have the = following comments on this draft = (draft-ietf-idr-bgp-ls-segment-routing-rld):

1) ERLD means Entropy capable Readable Label Depth as defined = in this draft. However, it said "...A network node signalling an ERLD = MUST support the ability to read the signalled number of labels before = any action is done upon the packet..." I'm wondering what actions other = than the EL-based LB action the "any action" could be since the ERLD has = been tightly coupled with the EL-based LB mechanism. In contrast, the = RLD as defined in the two IGP drafts is not tightly couple with the = EL-based LB action. In other words, the RLD capability could be = applicable to other use cases besides the EL-based LB.


GV> This is exactly what I asked = during the IETF100 IDR slot when I presented the updated work. The = consensus was that signalling of a readable label depth has entropy as = the dominant use-case scenario. This is now documented = in: 
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. Consensus from IETF100 IDR meeting was that ERLD is the way = forward for BGP-LS based signalling, and that maybe this should also be = the case for both ISIS and OSPF drafts (however, that is different = discussion).  I agree with IDR consensus and it seems the most = pragmatic path forward.


2) It said "...In existing technology both ISIS [4] and OSPF = [3] have proposed extensions to signal the RLD (Readable Label Depth) = and ELC (Entropy Label Capability) of a node or link. " However, there = is no extensions to signal the RLD and ELC of a link, if I remembered = correctly as a co-author of the above two IGP drafts:) In fact, when the = two IGP drafts were initially proposed, some guys does argue why not = advertise ELC and RLD of the per-link granularity as well. After some = discussion in IETF, a rough consensus had been reached that the = advertisement of ELC and RLD at a per node granularity was good enough = at that time. That's the reason why the two IGP drafts had not been = extended to advertise ELC and RLD at a per link granularity therefore. = Maybe we should reopen such discussion now?


GV> I have no intend to open up that = discussion at all, as it seems a pragmatic consensus was reached. = Steering seems to become more complex when link based ERLD is proposed = and a potential set of different ERLDs are signalled due to capabilities = of the line-card HW.  If for https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 we just need = node based ERLD, then I that is just fine. My personal opinion is that = we need node ERLD for node for sure in BGP-LS, and that link ERLD is a = nice to have. It seems relative easy and pragmatic to add both Link and = node ERLD in current version of the BGP-LS ERLD document.

3) It said "...if a network SDN controller is connected to = the network through a BGP-LS session and not through ISIS or OSPF = technology, then both RLD and ELC needs to be signaled in BGP-LS = accordingly.  This document describes the extension BGP-LS requires = to transport the combination of RLD and ELC into according ERLD = attributes for nodes and links..." I have not yet found any explanation = about the motivation for advertising the combination of RLD and ELC into = according ERLD attributes rather than advertising these two attributes = separately. Would it be better to give any explanation about such = motivation in the Problem Statement section?



GV> Yes, indeed, again that was = reason again that the work was presented during IETF100 as I had some = doubts myself. During IETF100 IDR meeting, I learned and was confirmed = that ERLD is now in the SPRING entropy label draft and that hence ERLD = is to be signalled for the most prominent use-case driving readable = label depth signalling
https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07. I see no reason to open that discussion again, and current = BGP-LS ERLD draft is inline the most dominant use-case scenario (Entropy = based load-balancing). I could change the existing text to refer = to https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-labe= l-07 and only mention ERLD (and no longer mention ELC/RLD at = all) if IDR WG find that better?

Brgds,

G/

Best = regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----=E5=8F=91=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 12:16
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Les Ginsberg = (ginsberg); Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: RE: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Xu,

I am arguing the exact opposite of what = you are saying.

Let us leave ELC/ERLD aside = since it is very limited to entropy label use-case and
the = proposed IGP/BGP-LS encoding is very specific to that. I am not sure if = this is
the time anymore to revisit that.

The MSD proposal came later and I support is since I've found = its use to be
much more widespread and the proposed = IGP/BGP-LS protocol encoding to be
very efficient as an = implementer of these protocols. Hence the request to not
restrict it to "writable" or "imposition" cases solely. It is = also not just about
"readability" - which by itself is = pretty meaningless. Even ERLD is about
"reading" and then = "doing *something specific* about it" as discussed in
ietf-spring-segment-routing-mpls.

There is no second thoughts about the IGP ELC drafts and they = are very useful
and necessary. Just to be clear there is = *no functional or operational change*
that I am arguing = for here. The discussion is purely on the way to handle these
encodings and whether we can use the MSD mechanism in a = generalized
manner.

Thanks,
Ketan

-----Original = Message-----
From: Xuxiaohu [mailto:xuxiaohu@huawei.com]
Sent: 21 = December 2017 08:10
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; = Ketan Talaulikar (ketant)
<ketant@cisco.com>; = Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: =E7=AD=94=E5=A4=8D: [Isis-wg] WG Last Call for = draft-ietf-isis-segment-routing-msd-07

Hi = Les,

If I understand it correctly, the MSD = concept was originated from
(https://tools.ietf.org/html/draft-ietf-pce-segment-routing-11#p= age-7) as
described below:

"The "Maximum SID Depth" (1
  octet) = field (MSD) specifies the maximum number of SIDs (MPLS label
  stack depth in the context of this document) that = a PCC is capable of
  imposing on a packet."

Before considering expanding the semantics of = the MSD concept as defined in
the above PCE-SR draft, how = about first considering renaming the capability of
imposing = the maximum number of labels so as to eliminate possible confusions,
e.g., Writable Label-stack Depth (WLD) as opposed to the = Readable Label-stack
Depth (RLD) as defined in (https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc)
and (https://tools.ietf.org/html/draft-ietf-isis-mpls-elc) = ?

Best regards,
Xiaohu

-----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA: Isis-wg [mailto:isis-wg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Les = Ginsberg
(ginsberg)
=E5=8F=91=E9=80=81=E6=97=B6= =E9=97=B4: 2017=E5=B9=B412=E6=9C=8821=E6=97=A5 4:02
=E6=94=B6=E4=BB=B6=E4=BA=BA: Ketan Talaulikar (ketant); = Christian Hopps; isis-wg@ietf.org
=E6=8A=84=E9=80=81: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
=E4=B8=BB=E9=A2=98: Re: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Ketan -

Thanx for the = comments.
I think we do want to allow MSD support for = values other than
imposition values. We will revise the = text so we are not restricted to only
imposition cases.

 Les


-----Original Message-----
From: Ketan = Talaulikar (ketant)
Sent: Wednesday, December 20, 2017 = 1:51 AM
To: Christian Hopps <chopps@chopps.org>; isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: RE: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07

Hello,

I support this document = and would like to ask the authors and WG to
consider if we = can expand the scope of this draft to not just
"imposition" = of the SID stack but also other similar limits related
to = other
actions (e.g.
reading, processing, etc.). With Segment = Routing, we are coming
across various actions that nodes = need to do with the SID stack for
different purposes and = IMHO it would be useful to extend the MSD
ability to cover = those as they arise.

Thanks,
Ketan

-----Original = Message-----
From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of
Christian Hopps
Sent: 20 December 2017 14:03
To: isis-wg@ietf.org
Cc: isis-ads@ietf.org; draft-ietf-isis-segment-routing-msd@ietf.org
Subject: [Isis-wg] WG Last Call for
draft-ietf-isis-segment-routing-msd-07


The authors have asked for and we are starting = a WG Last Call on


https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routin= g-msd
/

which will last = an extended 4 weeks to allow for year-end PTO patterns.

An IPR statement exists:


https://datatracker.ietf.org/ipr/search/?submit=3Ddraft&id=3D= draft-ietf-
is
is-
segment-routing-msd

Authors = please reply to the list indicating whether you are aware of
any
*new* IPR.

Thanks,
Chris.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
_____________________________________= __________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

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

= --Apple-Mail=_C869F3AC-7CFD-460B-9EFE-8B200A03CDDD-- From nobody Mon Dec 25 22:28:58 2017 Return-Path: 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 1F6FD126CF9 for ; Mon, 25 Dec 2017 22:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2KIDlOSQSRVh for ; Mon, 25 Dec 2017 22:28:55 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 7A3A0120727 for ; Mon, 25 Dec 2017 22:28:55 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 46EE4326E82AA for ; Tue, 26 Dec 2017 06:28:52 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 26 Dec 2017 06:28:53 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.231]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Tue, 26 Dec 2017 14:28:46 +0800 From: "Zhuangyan (Yan)" To: "jgs@juniper.net" , "idr@ietf.org" Thread-Topic: Re: [Idr] WGLC for draft-ietf-idr-ls-trill-03 Thread-Index: AdN+Eh+3hiC8xBNAQV2oN2n++AvjSw== Date: Tue, 26 Dec 2017 06:28:45 +0000 Message-ID: <9B4BC45FDEDDD84F813E9E4A5BAF8785A96811A0@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.170.230] Content-Type: multipart/alternative; boundary="_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96811A0nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] WGLC for draft-ietf-idr-ls-trill-03 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 06:28:57 -0000 --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96811A0nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft and do not know of any IPR related to it. Best Regards, Yan -----Original Message----- From: John Scudder [mailto:jgs at juniper.net] Sent: Thursday, October 19, 2017 10:34 AM To: idr@ietf. org Cc: draft-ietf-idr-ls-trill at ietf.org; trill at ietf.org Subject: WGLC for draft-ietf-idr-ls-trill-03 Hi All, An IDR working group last call has been requested for draft-ietf-idr-ls-tri= ll-03. Please reply to the list with your comments. As usual note we cannot= advance the draft without participation from the group. Please get your co= mments in before November 3, 2017. Authors, please confirm that any relevant IPR has been disclosed. https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03 Thanks, --John --_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96811A0nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this draft and do not know of any IPR rela= ted to it.

 

Best Regards,

 

Yan

 

-----Original Message-----

From: John Scudder [mailto:jg= s at juniper.net]

Sent: Thursday, October 19, 2017 10:34 AM=

To: idr@ietf. org

Cc: draft-ietf-idr-ls-trill at ietf.org; trill at ie= tf.org

Subject: WGLC for draft-ietf-idr-ls-trill-03

 

Hi All,

 

An IDR working group last call has been requested fo= r draft-ietf-idr-ls-trill-03. Please reply to the list with your comments. = As usual note we cannot advance the draft without participation from the gr= oup. Please get your comments in before November 3, 2017.

 

Authors, please confirm that any relevant IPR has be= en disclosed.

 

https://tools.ietf.org/html/draft-ietf-idr-ls-trill-03

 

Thanks,

 

--John

--_000_9B4BC45FDEDDD84F813E9E4A5BAF8785A96811A0nkgeml513mbschi_-- From nobody Tue Dec 26 06:01:34 2017 Return-Path: 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 E6BF0126FB3; Tue, 26 Dec 2017 06:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ok90acIpT49P; Tue, 26 Dec 2017 06:01:30 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (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 1B1931243FE; Tue, 26 Dec 2017 06:01:30 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id p31so24602610ota.4; Tue, 26 Dec 2017 06:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc; bh=IKHqmsXfFEaBlafbSEsQ+oNCn64bEGH+qhdC0ML61jA=; b=aFOsSjvJbNlr7zpBDkoxI042rSjF9bNGq0LPCPNo5zwqa8kTgh1T/SzuS7hKPayyJv hXTAwmVU/Pq9XAuAF7iHgVpujZ1pPxeI5AHJVFoJwaIvKFWEGnpVxzm0QosY7+eBEhNg 8yzl8g0aPJhzhfWoPmBtArGS4VLMRoPw2PCD7ZZ58OrqhkhhWteyBTy4FVKqU63UAfGF nnsn3hrv3apChKFVP4FbywLliUcd/PV2OpA3G3EAUUDW1kLrGpubUkPJpjkaKtLWxwYa 5k3hTtnhXcgyNd2azlST72YaEj088QhytNAOGLV+L/pJ7rHfYZII6ZTVJuPDc349mxLC YaDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc; bh=IKHqmsXfFEaBlafbSEsQ+oNCn64bEGH+qhdC0ML61jA=; b=FQMOx2C7v97Y1E0YTTpuILII2cVXtC5nBWsdi9KpnWQkBI8wJG4mgsuLN1BH8wMutK 6+VcgItgL+DT7l+J/r0sUNngaClgwFUXPFR9huSKah9FyMtGz78G1okkcbKSFFyMCK2t lDh/KzfaLX9lwxW6JI+UFW76VVeRIIUXG4bdaFuW0mTmpCVu2RbqH15BEw2gFfSaTn0J PSnOSYQVAFt22HLAJJ01O+/C20E/z2GkYndU2zHbV7CiVq5xpOFrRIrBuOZ610H3M7KO Jx31kgD0LYFseREIsYIzErgi7KXJxo+2a8un9e3KcTG+p8uzmb1vzU28fDAqwb3BdxJB Fq9w== X-Gm-Message-State: AKGB3mIZEWCYY7f2jC9Er0KmP/Cr5Uo47k2RsHqUbs0J9pM7vr0SbO1L M0p7wj7IO2IQbKFJtOXDCrf3SBSbAqPSItG7wBI= X-Google-Smtp-Source: ACJfBot7UyyfF5LhP7N/jboiVDs1dfdykNUuFXkCgKfcRw0grV2NFl9+yNQEgEysrs9dT2WTAuID54awNTYCVGKZdPA= X-Received: by 10.157.53.5 with SMTP id o5mr4934719otc.307.1514296889297; Tue, 26 Dec 2017 06:01:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 26 Dec 2017 09:01:28 -0500 From: Alvaro Retana X-Mailer: Airmail (467) MIME-Version: 1.0 Date: Tue, 26 Dec 2017 09:01:28 -0500 Message-ID: To: Eric C Rosen , draft-ietf-idr-bgp-prefix-sid@ietf.org Cc: idr-chairs@ietf.org, Susan Hares , idr@ietf.org Content-Type: multipart/alternative; boundary="001a11c046c42bd03705613eb8bf" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-prefix-sid-07 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 14:01:33 -0000 --001a11c046c42bd03705613eb8bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On December 22, 2017 at 10:50:25 AM, Eric C Rosen (erosen@juniper.net) wrote: Hi! On 12/21/2017 4:52 PM, Alvaro Retana wrote: I don't think the following point is correct. After thinking about it some more, Eric's right...for the MPLS dataplane where the attribute contains the index. But for IPv6 the attribute contains the SID itself =E2=80=94 see more below= . (2) Error Handling The error handling (in Section 6) specifies that =E2=80=9Cattribute discard= =E2=80=9D (rfc7606) should be used if the attribute is malformed. I think that behavior has a direct effect on the path used to forward the traffic, which puts it then in conflict with rfc7606 because it clearly says that "Attribute discard...MUST NOT be used except in the case of an attribute that has no effect on route selection or installation.=E2=80=9D = Please see M9 below. M9. If the attribute is malformed then the index or SID in it won=E2=80=99= t be used by the receiver (attribute discard) as specified in Section 6. Section 4.1 explains how a local label is assigned if the BGP Prefix-SID attribute is unacceptable. M9.1. I=E2=80=99m assuming that the local label assignment in 4.1 includes = the case when the attribute is malformed (i.e. not just the unacceptable case). Is that true? Using a local label would result in successfully delivering the traffic to the destination, but not using the intended SR path, right? If that is true, then the malformed attribute case would have an effect on route selection/installation and could result (among other things) in the traffic taking an unwanted path due to policy, a path that is congested, etc.=E2=80=A6and that is explicitly the case where rfc7606 specifies that a= ttribute discard MUST NOT be used. It seems that any action beyond attribute discard may be too harsh given that a local label can be assigned=E2=80=A6b= ut the current specification ("MUST treat the path as if it came without a Prefix-SID attribute...MUST assign a local (also called dynamic) label=E2= =80=9D) is in conflict with rfc7606. I would be ok if the document explained the potential issues and made the local label behavior optional (pending a discussion in the WG and maybe an update to rfc7606). BTW, was this discussed in the WG (I couldn=E2=80=99t find a related discussion in the ar= chive)? The presence of absence of the prefix-SID attribute is not taken into account in any way by the BGP bestpath selection process, so it has no effect on "route selection or installation". Thus I don't see any conflict between this draft and RFC 7606. If I understand correctly, the intention of the prefix-SID attribute on a BGP-LU route is the following. When a router receives a BGP-LU route for prefix X with label L1, it propagates that that route with a locally assigned label L2. The prefix-SID attribute tells the router what the value of L2 should be. But if the router uses a different value of L2, that doesn't change the path followed by the data. Thus "treat as withdraw" does not seem like the proper response to a malformed prefix-SID attribute, whereas "attribute-discard" seems appropriate. I'm less sure what the impact of a malformed prefix-SID attribute is when the dataplane is not MPLS. Using the example in Section 5. (Applying Segment Routing in the DC with IPv6 dataplane) of draft-ietf-spring-segment-routing-msdc [1]. If the BGP Prefix-SID attribute is malformed (=E2=80=9Cattribute discard=E2=80=9D) in = the advertisement from Node5, then (as currently written in the document) the rest of the network wouldn=E2=80=99t know which SID to use=E2=80=A6this mea= ns that the expected result of the example: "HostA which needs to send traffic to HostZ via only Node5 (spine node) can do so by sending IPv6 packets with a SRH extension header=E2=80=9D can=E2=80=99t be realized. The result would then= be that the traffic could be delivered to Node11, but maybe not through Node5. While the attribute is not taken into account in the BGP selection process, it is clear to me that the resulting paths are impacted because not all the expected routes are installed as a result of a malformed attribute. I found this related text in Section 8. (Guidance for Authors of BGP Specifications) of rfc7606: For any malformed attribute that is handled by the "attribute discard" instead of the "treat-as-withdraw" approach, it is critical to consider the potential impact of doing so. In particular, if the attribute in question has or may have an effect on route selection or installation, the presumption is that discarding it is unsafe unless careful analysis proves otherwise. The analysis should take into account the tradeoff between preserving connectivity and potential side effects. I think this is one of those cases where the combination of a policy (=E2= =80=9Csend traffic via Node5=E2=80=9D) and a discarded attribute (resulting in no SID = for Node5) could result in an unanticipated effect=E2=80=A6yes, not directly re= lated to the selection process, but to the paths that can be installed and used. In line with the text above, I would be happy if some analysis was written into the text: Just like in the MPLS case, there could be an alternate procedure that could be used to still be able to instantiate the desired path=E2=80=A6or simply making operators aware of the potential effect of di= scarding the attribute would be enough. Thanks! Alvaro. [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-msdc-05#secti= on-5 --001a11c046c42bd03705613eb8bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On December 22, 2017 at 10:50:25 AM, Eric C Rosen (erosen@juniper.net) wrote:

Hi!

=
On 12/21/2017 4:52 PM, Alv= aro Retana wrote:

I don't think the following point is correct.<= /font>

Aft= er thinking about it some more, Eric's right...for the MPLS dataplane w= here the attribute contains the index.

But for IPv6 the attribute contains the SID itself =E2=80=94 see more bel= ow.

(= 2) Error Handling

T= he error handling (in Section 6) specifies that=C2=A0=E2=80=9Cattribute dis= card=E2=80=9D (rfc7606)=C2=A0should be used if the attribute is malformed.= =C2=A0 I think that behavior has a direct effect on the path used to forwar= d the traffic, which puts it then in conflict with rfc7606 because it clear= ly says that "Attribute discard...MUST NOT be used except in the case = of an attribute=C2=A0that has no effect on route selection or installation.= =E2=80=9D =C2=A0Please see M9 below.


M9= .=C2=A0 If the attribute is malformed then the index or SID in it won=E2=80= =99t be used by the receiver (attribute discard) as specified in Section 6.= =C2=A0 Section 4.1 explains how a local label is assigned if the BGP Prefix= -SID attribute is unacceptable.

M9.1. I=E2=80= =99m assuming that the local label assignment in 4.1 includes the case when= the attribute is malformed (i.e. not just the unacceptable case).=C2=A0 Is= that true? =C2=A0 Using a local label would result in successfully deliver= ing the traffic to the destination, but not using the intended SR path, rig= ht?=C2=A0 If that is true, then the malformed attribute case would have an = effect on route selection/installation and could result (among other things= ) in the traffic taking an unwanted path due to policy, a path that is cong= ested, etc.=E2=80=A6and that is explicitly the case where rfc7606 specifies= that attribute discard MUST NOT be used.=C2=A0 It seems that any action be= yond attribute discard may be too harsh given that a local label can be ass= igned=E2=80=A6but the current specification ("MUST treat the path as i= f it came=C2=A0without a Prefix-SID attribute...MUST assign a local (also c= alled dynamic)=C2=A0label=E2=80=9D) is in conflict with rfc7606. =C2=A0 I w= ould be ok if the document explained the potential issues and made the loca= l label behavior optional (pending a discussion in the WG and maybe an upda= te to rfc7606).=C2=A0 BTW, was this discussed in the WG (I couldn=E2=80=99t= find a related discussion in the archive)?


The presence of absence of the pref= ix-SID attribute is not taken into account in any way by the BGP bestpath s= election process, so it has no effect on "route selection or installat= ion".=C2=A0 Thus I don't see any conflict between this draft and R= FC 7606.

If I understand correctly, the intention of the prefix-SID = attribute on a BGP-LU route is the following.=C2=A0 When a router receives = a BGP-LU route for prefix X with label L1, it propagates that that route wi= th a locally assigned label L2.=C2=A0 The prefix-SID attribute tells the ro= uter what the value of L2 should be.=C2=A0 But if the router uses a differe= nt value of L2, that doesn't change the path followed by the data.=C2= =A0 Thus "treat as withdraw" does not seem like the proper respon= se to a malformed prefix-SID attribute, whereas "attribute-discard&quo= t; seems appropriate.

I'm less sure what the impact of a malform= ed prefix-SID attribute is when the dataplane is not MPLS.

Using the example in Section=C2=A05. (Applying = Segment Routing in the DC with IPv6 dataplane) of=C2=A0draft-ietf-spring-segment-routing-msdc [1].=C2=A0 If the BGP Prefix-SID attribute is malformed (=E2=80=9Cattribute discard=E2=80=9D)= in the advertisement from Node5, then (as currently written in the document) the r= est of the network wouldn=E2=80=99t know which SID to use=E2=80=A6this means that the expected result of the ex= ample: "HostA which needs to send traffic to HostZ via only Node5 (spine node) can do so by sending IPv6 packets with a SRH extension header=E2=80=9D can=E2=80=99t be realized.=C2=A0 The result would then be that the traffic could be delivered to Node11, but maybe not through Node5.

While the attribute is not taken into account i= n the BGP selection process, it is clear to me that the resulting paths are= impacted because not all the=C2=A0expected routes are installed as a resul= t of a malformed attribute.=C2=A0 I found this related text in Section=C2= =A08. (Guidance for Authors of= BGP Specifications) of=C2=A0r= fc7606:

   For any malformed attribute tha=
t is handled by the "attribute
   discard" instead of the "treat-as-withdraw" approach, it =
is critical
   to consider the potential impact of doing so.  In particular, if the
   attribute in question has or may have an effect on route selection or
   installation, the presumption is that discarding it is unsafe unless
   careful analysis proves otherwise.  The analysis should take into
   account the tradeoff between preserving connectivity and potential
   side effects.
I think this is one of those cases where the combination of a po= licy (=E2=80=9Csend traffic via Node5=E2=80=9D) and a discarded attribute (= resulting in no SID for Node5) could result in an unanticipated effect=E2= =80=A6yes, not directly related to the selection process, but to the paths = that can be installed and used.=C2=A0 In line with the text above, I would = be happy if some analysis was written into the text: =C2=A0Just like in the= MPLS case, there could be an alternate procedure that could be used to sti= ll be able to instantiate the desired path=E2=80=A6or simply making operato= rs aware of the potential effect of discarding the attribute would be enoug= h.

Thanks!

Alvaro.

[1]=C2=A0https://tools.ietf.or= g/html/draft-ietf-spring-segment-routing-msdc-05#section-5=C2=A0=

--001a11c046c42bd03705613eb8bf-- From nobody Tue Dec 26 14:46:48 2017 Return-Path: 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 2C49D120725; Tue, 26 Dec 2017 14:46:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151432840213.29737.13805654837895832751@ietfa.amsl.com> Date: Tue, 26 Dec 2017 14:46:42 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-te-lsp-distribution-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.22 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 22:46:42 -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 : Distribution of Traffic Engineering (TE) Policies and State using BGP-LS Authors : Stefano Previdi Jie Dong Mach(Guoyi) Chen Hannes Gredler Jeff Tantsura Filename : draft-ietf-idr-te-lsp-distribution-08.txt Pages : 27 Date : 2017-12-26 Abstract: This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a router and advertise it into BGP-LS updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-te-lsp-distribution/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-te-lsp-distribution-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-te-lsp-distribution-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-te-lsp-distribution-08 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/